Replies: 6 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.
-
The problem with the current implementation of the issue_comment event is that it can only trigger workflows if the workflow file is on the default branch. This limitation complicates the process of modifying and testing workflows, as changes must be merged into the default branch first. Additionally, it adds complexity to building workflows that need to run against specific branches, requiring extra steps to configure the workflow context correctly. Allowing the issue_comment event to trigger workflows from non-default branches would greatly enhance flexibility and ease of development. For instance, it would streamline workflows triggered by comments on pull requests by eliminating the need for additional steps to checkout and configure branch contexts. For more visit our site. |
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