Replies: 8 comments
-
Yes, please. I'm facing the same situation. We want to implement some rules that interact with github comments, but is only possible to validate after merge the branch to master! |
Beta Was this translation helpful? Give feedback.
-
It is unbelievable that this is the default behavior. I can even consider the possibility of understanding it for issues, but definitively not for PRs. It is quite obvious that if I want to trigger a workflow using a comment on a Pull Request I want the code to be considered from that Pull Request HEAD version. If we need to use another event Also, it would be very important to have the documentation stating this behavior very clearly, since it is not aligned with the behavior of (almost?) all other events. |
Beta Was this translation helpful? Give feedback.
-
🕒 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.
-
Just updating to not let be labeled as dormant. It is a really annoying behaviour |
Beta Was this translation helpful? Give feedback.
-
It's frustrating, a workflow that can be executed manually ('workflow_dispatch') or by a call ('workflow_call') might give different feedbacks. For example, such workflow can be a deploy workflow. Running it manually will show the deployment on the PR's page (since it takes the context of the head commit), but running from a command does not, and requires 3rd party actions to do something alike. Still didn't find a solution for it to have the same results. |
Beta Was this translation helpful? Give feedback.
-
same frustration here ... this should behave almost the same way as on pull_request / labeled ! |
Beta Was this translation helpful? Give feedback.
-
It's frustrating that I have to merge a workflow into the default branch just to test it because @github actions only trigger issue_comment events from the main branch. This makes workflow development a pain. |
Beta Was this translation helpful? Give feedback.
-
I am in the same boat. We are trying to run Playwright on PR and need the "issue" event to fetch vercel deployment link. :( |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
What's the problem?
Currently, the
issue_comment
event can only trigger workflows, if the workflow file is on the default branch (see docs).This makes it difficult to:
It would be extremely useful to allow this event to trigger workflows from non-default branches.
Example use-case
For example, when building a workflow to trigger a workflow from a comment on a pull request, we need to make sure to add in a step in the workflow to checkout the branch, and make sure the github context/refs are configured properly.
Related discussions and resources
issue_comment
event? actions/checkout#331Beta Was this translation helpful? Give feedback.
All reactions