More flexible triggers in Github Actions #108268
Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
Hello,
I have a request regarding triggers in Github Actions.
Often I find the triggers to be not flexible enough.
One scenario we often encounter is PRs being opened by automation tools as drafts, which should not trigger CI runs until they are "Ready for Review".
As far as I understand only the transitional states
converted_to_draft
andready_for_review
are possible triggers, but not the condition "PR is a draft PR".So every PR
synced
event triggers a workflow run, in which I then can check forif: github.event.pull_request.draft == 'false'
and stop the run. But to get this far a runner has to be used. Is there no other way to achieve this before starting the workflow? Something like a logicalAND
for triggers along the lines ofsynchronize && ready_for_review
?Another scenario is running workflows on certain branches only. When setting things up like this:
and push a commit to a branch
renovate/TEST
thepull_request
trigger still fires because I can't restrict it to a source branch. Why is there only an option to restrict the TARGET branch forpull_request
? Which is very confusing, being named the same as forpush
where it is the other way around btw.And the last scenario we have issues with is restriction triggers by author. Why is there no such trigger setting as:
to exclude some authors, machine accounts in our use case, from triggering workflows? The information is there in the moment the push happens. Again I would have to spin up a runner and do the check inside the workflow instead of beforehand.
I'm eager to understand the design decisions and hear your thoughts and maybe get ideas on how to circumvent these issues.
Best regards,
Norman
Beta Was this translation helpful? Give feedback.
All reactions