Note major versions are not automatically tagged

[Kurt-von-Laven]

The previous wording can be misinterpreted to suggest that GitHub Actions itself automatically tags major versions.

Also, remove assurance that pinning the major version protects your workflow from breaking. This is only true if the action you depends on never introduces any bugs that affect you. In other words, it's false in practice. The new copy seeks to highlight that the three presented options form a continuum from maximum security/stability, minimum convenience to minimum security/stability, maximum convenience.

Why:

Closes #17071.

What's being changed:

See rich diff.

Check off the following:

• I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
• For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

• This pull request impacts the contribution experience
  • I have added the 'writer impact' label
  • I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
content/actions/using-workflows/workflow-syntax-for-github-actions.md	Modified	Original

[Kurt-von-Laven]

In case anyone is following this thread, evidently when Octomerger merges a batch of pull requests at once, GitHub incorrectly states that the author of each PR force-pushed their own branch, which, to be clear, I didn't, and automatically closes the pull request as if it had not been merged (which it has).

[ramyaparimi]

Ah!! That explains why I never triaged this since it shows that the author closed the PR. I will let the team know about this.

In the mean time, could you let me know if this PR has to be re-opened and triaged?

Ah!! So weird, I am not able to re-open the PR, probably because the branch for this PR is deleted.
I will check with the team on this and get back to you. Thanks so much for your patience 💛 .

[Kurt-von-Laven]

Yeah, it's probably worth bringing up simply because it's somewhat confusing for those who aren't familiar with the inner workings of Octomerger. There's no action needed specific to this PR, because it has already been merged by Octomerger. You are correct that PRs cannot be reopened once the branch has been deleted, although even if that weren't true, there would be nothing left on the branch (that isn't already on main) to merge at this point. Thanks for noticing my random comment on a closed PR in any case!

[ramyaparimi]

Thanks so much for your valuable insights and contributions to the GitHub docs 💖 .

[Kurt-von-Laven]

Hmm... it appears I was mistaken, and this change was never merged to main. This pull request replaced "Using the specific major action version allows you to receive critical fixes and security patches while still maintaining compatibility. It also assures that your workflow should still work." with "If the action publishes major version tags, using them allows you to receive critical fixes and security patches while still maintaining compatibility." You can no longer see the original diff here on account of it having been merged, but the orphaned commit remains as evidence of this. The Octomerger force-push actually includes the opposite change, which explains why my change never appeared. This does seem like a more serious bug in Octomerger than I initially realized. In summary, Octomerger automatically closed this pull request without merging it, and this action was displayed in the GitHub UI as a force-push by me that I didn't actually do.

[ramyaparimi]

@Kurt-von-Laven Thanks so much for the detailed feedback. I will let our engineering team know about this. Thanks so much for your patience and time in improving GitHub docs 💖

[rachmari]

@Kurt-von-Laven @ramyaparimi this certainly looks like a bug. I've opened an internal engineering issue to take a look at it. Thank you for reporting this and I apologize for the inconvenience.