GitHub Community
-
Select Topic AreaQuestion What's the problem?Currently, the This makes it difficult to:
It would be extremely useful to allow this event to trigger workflows from non-default branches. Example use-caseFor 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 |
Beta Was this translation helpful? Give feedback.
Replies: 31 comments 3 replies
-
|
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.
-
|
it is especially painful for big projects that have dozen devs and tens of minutes of tests to run for each PR, the blockages it created in the dev process for us is unbelievably high and for no good reason |
Beta Was this translation helpful? Give feedback.
-
|
Bump |
Beta Was this translation helpful? Give feedback.
-
|
BUMP! |
Beta Was this translation helpful? Give feedback.
-
|
Hey y'all |
Beta Was this translation helpful? Give feedback.
-
|
Adding in my support - have just tried to make an action from my companies PR's using this feature to grab info from a comment and write it to a spreadsheet! This would be super valuable and really appreciated ❤️🔥 |
Beta Was this translation helpful? Give feedback.
-
|
It would be great to have this feature to execute the github actions based on the Pull request comments from a non-default branch. This would help to trigger separate workflows based on the comments in the PR and I am currently looking for such a use case, where the workflow could be triggered based on a pull request comment, I also need to fetch that comments and pass it to the workflow |
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.
-
|
Not dormant. |
Beta Was this translation helpful? Give feedback.
-
|
Bump |
Beta Was this translation helpful? Give feedback.
-
|
Guys, any updates on this? Any workaround? |
Beta Was this translation helpful? Give feedback.
-
|
Just spent like 30 minutes trying to figure this out. I've used this workflow before but set it up a long time ago. I was trying it at a new job on a new repo and... 💀 |
Beta Was this translation helpful? Give feedback.
-
|
As @chrisleves mentioned, a plausible workaround is to use the labeled type pull_request / pull_request_target event. on:
pull_request:
types:
- labeledon:
pull_request_target:
types:
- labeledAnd we would need to add a custom tag to the repo through repo main page > issues > labels, say we add a new tag "done", we could perform the following check: jobs:
my_job:
if: ${{ github.event.label.name == 'done' }}This would essentially create a user-friendly trigger through appending the custom tag to a PR, and we could re-trigger this through untagging and tagging again. However, for more complex usage like the content moderation of the PR thread, we would still need the issue_comment event to be triggered on non-default branches. |
Beta Was this translation helpful? Give feedback.
-
|
bump |
Beta Was this translation helpful? Give feedback.
-
|
This is still very relevant, almost 2 years and nothing on the backlog for this increment? We're struggling to test pipelines because of this constraint. |
Beta Was this translation helpful? Give feedback.
-
|
@lorainegarutti Don't know if you are still having issues testing your pipelines, but something that has worked for me is to utilize |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 again, the 2025 is almost over and we still do not have this super-important feature... |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Just have codex or CC go in and fix this, you can just do things! |
Beta Was this translation helpful? Give feedback.
-
|
tripped over this again today. it's very hard to test existing GHA workflows that rely on for those who are stuck, one possible path is: see if you can temporarily disentangle the stuff you want to test from the stuff that depends on the comment. then set up a dummy workflow that triggers on something like |
Beta Was this translation helpful? Give feedback.
-
|
I've come up with a bit of a hacky workaround, inspired by @vivshaw's comment above. I have one workflow that listens to Example:
name: On Issue Comment
on:
issue_comment:
types: [created]
permissions:
actions: write # needed to dispatch workflows
pull-requests: read
jobs:
check-pr-comment:
if: ${{ github.event.issue.pull_request && github.event.issue.state == 'open' }}
runs-on: ubuntu-latest
steps:
- name: Trigger workflow
uses: actions/github-script@v7
with:
script: |
const pr = await github.rest.pulls.get({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.issue.number,
});
await github.rest.actions.createWorkflowDispatch({
workflow_id: 'on-pr-comment.yaml',
owner: context.repo.owner,
repo: context.repo.repo,
ref: pr.data.head.ref,
inputs: {
comment: JSON.stringify(context.payload.comment),
issue: JSON.stringify(context.payload.issue),
},
})
# This workflow is designed to be triggered from the on-issue-comment.yaml workflow
# This workflow should run on the head ref of the PR the comment was posted on
name: "On PR Comment"
on:
workflow_dispatch:
inputs:
comment:
description: 'JSON string of the comment payload from the issue_comment event'
required: true
type: string
issue:
description: 'JSON string of the issue payload from the issue_comment event'
required: true
type: string
jobs:
pr-comment:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Simple trigger
if: ${{ contains(fromJSON(inputs.comment).body, '!test') }}
run: |
echo "Running tests for PR #${{ fromJSON(inputs.issue).number }}"
- name: Check trigger in script
uses: actions/github-script@v7
env:
COMMENT: ${{ inputs.comment }}
ISSUE: ${{ inputs.issue }}
with:
script: |
const comment = JSON.parse(process.env.COMMENT);
const issue = JSON.parse(process.env.ISSUE);
if (comment.body.includes('!deploy')) {
console.log(`Deploying PR #${issue.number}`);
} else if (comment.body.includes('!test')) {
console.log(`Testing PR #${issue.number}`);
} else {
console.log(`No recognized command in comment for PR #${issue.number}`);
}The intent here is that |
Beta Was this translation helpful? Give feedback.
and others
Hey y'all
Sorry we have been quiet here, I have added this to our paper cuts backlog :) and we will have a go seeing where it falls.
I can say it isn't something we will address this calendar year, but we are aware of it and thank you all for engaging and giving the feedback. Keep it coming <3