-
Notifications
You must be signed in to change notification settings - Fork 63.9k
run-on-specific-branches-or-tags1: terminology fix #40824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines. |
How to review these changes 👓Thank you for your contribution. To review these changes, choose one of the following options: A Hubber will need to deploy your changes internally to review. Table of review linksNote: Please update the URL for your staging server or codespace. The table shows the files in the
Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server 🤖 This comment is automatically generated. |
|
@wh0 Thanks for opening a PR! Copilot tells me this is correct, and I would be inclined to trust it since this is a small change, if it hadn't just completely made up a citation for me. So. I think I'm going to verify with an actual person. |
| Use the `tags` filter when you want to include tag name patterns or when you want to both include and exclude tag names patterns. Use the `tags-ignore` filter when you only want to exclude tag name patterns. You cannot use both the `tags` and `tags-ignore` filters for the same event in a workflow. | ||
|
|
||
| If you define only `tags`/`tags-ignore` or only `branches`/`branches-ignore`, the workflow won't run for events affecting the undefined Git ref. If you define neither `tags`/`tags-ignore` or `branches`/`branches-ignore`, the workflow will run for events affecting either branches or tags. If you define both `branches`/`branches-ignore` and [`paths`/`paths-ignore`](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied. | ||
| If you define only `tags`/`tags-ignore` or only `branches`/`branches-ignore`, the workflow won't run for events affecting the undefined filter. If you define neither `tags`/`tags-ignore` or `branches`/`branches-ignore`, the workflow will run for events affecting either branches or tags. If you define both `branches`/`branches-ignore` and [`paths`/`paths-ignore`](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), the workflow will only run when both filters are satisfied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe filter is not right... but Git ref is not right either.
Because if branches-ignore is set, then the workflow is indeed affecting the undefined Git refs AFAIK.
If you define only
tags/tags-ignoreor onlybranches/branches-ignore, the workflow won't run for events affecting the undefined filter.
Maybe we can remove that ☝️ sentence all together because we already discuss the filters in the previous paragraphs. I am not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean if you set
on:
push:
# tags not set
# tags-ignore not set
branches-ignore: nobuildit will still run on all pushes to tags?
Why:
In this line, there isn't really such thing as "the undefined Git ref." Rather "defined" and "undefined" describe the
branches/tagsfilters when you define only one of them.Closes:
What's being changed (if available, include any code snippets, screenshots, or gifs):
Check off the following: