You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
is it redudant to run Copilot Setup Steps on push and pull_request? #42379
What part(s) of the article would you like to see updated?
I don't think it should be suggested to have both push and pull_request as workflow triggers in the sample copilot-setup-steps.yml.
Note
If you run on push the commit in the pull_request will already have a Check Run associated with it from the push workflow trigger, so pull_request workflow trigger seems redundant in the sample workflow below.
ex.
name: "Copilot Setup Steps"# Automatically run the setup steps when they are changed to allow for easy validation, and# allow manual testing through the repository's "Actions" tabon:
workflow_dispatch:
push:
paths:
- .github/workflows/copilot-setup-steps.ymlpull_request:
paths:
- .github/workflows/copilot-setup-steps.ymljobs:
# The job MUST be called `copilot-setup-steps` or it will not be picked up by Copilot.copilot-setup-steps:
runs-on: ubuntu-latest# Set the permissions to the lowest permissions possible needed for your steps.# Copilot will be given its own token for its operations.permissions:
# If you want to clone the repository as part of your setup steps, for example to install dependencies, you'll need the `contents: read` permission. If you don't clone the repository in your setup steps, Copilot will do this for you automatically after the steps complete.contents: read# You can define any steps you want, and they will run before the agent starts.# If you do not check out your code, Copilot will do this for you.steps:
- name: Checkout codeuses: actions/checkout@v5
- name: Set up Node.jsuses: actions/setup-node@v4with:
node-version: "20"cache: "npm"
- name: Install JavaScript dependenciesrun: npm ci
Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.
@brignano Thanks for opening an issue and PR! This is definitely one I'll have to take to the team to make sure there's no pressing reason it's documented the way it is.
Thanks for raising this. From a documentation standpoint, it would be helpful to clarify why both push and pull_request triggers are included in the example, especially since the same commit can already have a check run from the push event.
If there are cases where both triggers are required (for example, forks, permission differences, or required checks on pull requests), documenting that rationale could help readers understand when this configuration is intentional versus redundant.
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
Hi @brignano, thank you for raising this and please accept my apologies for a couple of things: the late reply, and for the poor experience you seem to have had when raising a PR about it.
I agree about the redundancy, technically, but I want to note that this particular workflow's intended as an illustrative snippet rather than necessarily something that we'd expect users to copy verbatim. Documenting workflows like this is a bit of a challenge.
What about adding a line to the copy here, instead? For example, we could add a line to this part:
Here is a simple example of a copilot-setup-steps.yml file for a TypeScript project that clones the project, installs Node.js and downloads and caches the project's dependencies. You should customize this to fit your own project's language(s) and dependencies.
(I've emboldened the operative part of that sentence, that's relevant here; I think we could make that particular sentence a bit more general, too.)
eg, we could remove the colon and add this sentence:
For example, you wouldn't typically run on both push and pull_request.
Thanks @subatoi — no apology needed, and that framing makes sense. I've reworked #45823 to do it in the copy instead; it's now a one-line change:
Here is a simple example of a copilot-setup-steps.yml file for a TypeScript project that clones the project, installs Node.js and downloads and caches the project's dependencies. You should customize this to fit your own project, including its language(s), its dependencies, and the workflow triggers you need. For example, you wouldn't typically run on both push and pull_request.
Two things you may want to weigh, though — both cut slightly against "not something we'd expect users to copy verbatim":
The snippet is fenced ```yaml copy, so it renders with a copy button.
Improve a project has Copilot generate the file from this article (the prompt passes the URL), and then shows the same on: block with both triggers.
So in practice this sample does get copied fairly literally. Entirely your call — happy to leave the YAML as-is, but if you'd rather scope the push trigger to the default branch as well, I have that commit ready.
To your other notes above, those are fair points. If you'd like to go ahead and remove the ```yaml copy fence, and edit the prompt you mentioned to make it clear that both triggers aren't needed, I'd be happy to accept a single combined PR, or two separate ones, for that 👍
If you'd like to go ahead with that, ideally you'd open one or two new issues at the same time, but I can do that retroactively if needed. I'll leave this issue open for now. Thanks for your help!
Thanks @subatoi! Both make sense. I've opened #45861 to track it, and gone with the single combined PR option: #45862.
It does three things:
Drops the copy annotation from the sample's fence in Configure the development environment, so the sample keeps its highlighting but no longer offers one-click copying.
Extends the step 2 prompt in Improve a project so the workflow Copilot generates gets a workflow_dispatch trigger and doesn't run on both push and pull_request.
Trims the extract below that prompt to the trigger and job name the surrounding sentence calls out — otherwise it would contradict the prompt it's there to help verify.
One I deliberately left out: the Git LFS snippet further down the same reference article is also fenced ```yaml copy, and it's a fragment starting with # ..., so the same reasoning arguably applies to it. Happy to fold it in if you'd like — I just didn't want to widen the PR past what you asked for.
The sample keeps both push and pull_request, but the surrounding text no longer presents it as a drop-in config, which addresses the confusion that prompted this. #45823 said "Fixes #42379" but repo-sync didn't propagate the close, hence closing manually.
Activity
welcome commentedon Jan 14, 2026
Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.
Sharra-writes commentedon Jan 23, 2026
@brignano Thanks for opening an issue and PR! This is definitely one I'll have to take to the team to make sure there's no pressing reason it's documented the way it is.
shelararti commentedon Jan 26, 2026
Thanks for raising this. From a documentation standpoint, it would be helpful to clarify why both
pushandpull_requesttriggers are included in the example, especially since the same commit can already have a check run from thepushevent.If there are cases where both triggers are required (for example, forks, permission differences, or required checks on pull requests), documenting that rationale could help readers understand when this configuration is intentional versus redundant.
github-actions commentedon Mar 3, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
github-actions commentedon Sep 7, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
subatoi commentedon Sep 9, 2026
Hi @brignano, thank you for raising this and please accept my apologies for a couple of things: the late reply, and for the poor experience you seem to have had when raising a PR about it.
I agree about the redundancy, technically, but I want to note that this particular workflow's intended as an illustrative snippet rather than necessarily something that we'd expect users to copy verbatim. Documenting workflows like this is a bit of a challenge.
What about adding a line to the copy here, instead? For example, we could add a line to this part:
(I've emboldened the operative part of that sentence, that's relevant here; I think we could make that particular sentence a bit more general, too.)
eg, we could remove the colon and add this sentence:
brignano commentedon Sep 10, 2026
Thanks @subatoi — no apology needed, and that framing makes sense. I've reworked #45823 to do it in the copy instead; it's now a one-line change:
Two things you may want to weigh, though — both cut slightly against "not something we'd expect users to copy verbatim":
```yaml copy, so it renders with a copy button.on:block with both triggers.So in practice this sample does get copied fairly literally. Entirely your call — happy to leave the YAML as-is, but if you'd rather scope the
pushtrigger to the default branch as well, I have that commit ready.subatoi commentedon Sep 10, 2026
Many thanks @brignano—I've merged #45823
To your other notes above, those are fair points. If you'd like to go ahead and remove the
```yaml copyfence, and edit the prompt you mentioned to make it clear that both triggers aren't needed, I'd be happy to accept a single combined PR, or two separate ones, for that 👍If you'd like to go ahead with that, ideally you'd open one or two new issues at the same time, but I can do that retroactively if needed. I'll leave this issue open for now. Thanks for your help!
brignano commentedon Sep 13, 2026
Thanks @subatoi! Both make sense. I've opened #45861 to track it, and gone with the single combined PR option: #45862.
It does three things:
copyannotation from the sample's fence in Configure the development environment, so the sample keeps its highlighting but no longer offers one-click copying.workflow_dispatchtrigger and doesn't run on bothpushandpull_request.One I deliberately left out: the Git LFS snippet further down the same reference article is also fenced
```yaml copy, and it's a fragment starting with# ..., so the same reasoning arguably applies to it. Happy to fold it in if you'd like — I just didn't want to widen the PR past what you asked for.brignano commentedon Sep 17, 2026
Closing this out. Resolved across two PRs:
copilot-setup-steps.ymlsamples are illustrative #45862 — marked thecopilot-setup-steps.ymlsamples as illustrative rather than copy-ready, and extended the tutorial prompt to tell readers to customize the triggersThe sample keeps both
pushandpull_request, but the surrounding text no longer presents it as a drop-in config, which addresses the confusion that prompted this. #45823 said "Fixes #42379" but repo-sync didn't propagate the close, hence closing manually.