GitHub/git protections
Open
Nobody has claimed this yet.
backlog
chore
- Dominant language
- Swift
- Stars
- 12.4k
- Forks
- 299
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 1
Description
Potential GitHub/git commit, branch & tag protections:
Tags
- Redo version tags without
vprefix?- Tags (
mas-cli/mas&mas-cli/homebrew-tap) - GitHub Releases (
mas-cli/mas&mas-cli/homebrew-tap)- Tag
- Name
- Body
- Custom tap formula (
mas-cli/mas&mas-cli/homebrew-tap) homebrew-coreformula- …?
- Tags (
- Configure & enable tag ruleset
- Disallow changing version tags.
- Ensure that each new release tag has one & only one semantic version component that is one greater than some other prior release version, followed by zeros for all subsequent components, with an optional -beta.1 suffix.
- So, the following version transitions are OK:
- 5.6.7 -> 6.0.0
- 5.6.7 -> 5.7.0
- 5.6.7 -> 5.6.8
- 5.6.7 -> 5.6.8-beta.1
- 5.6.7-beta.1 -> 5.6.7-beta.2
- While the following version transitions are not OK:
- (no stable 5.* exists) -> 6.0.0
- (no stable 5.6.* exists) -> 5.7.0
- (no stable 5.6.7.* exists) -> 5.6.8
- (no stable 5.6.7.* exists) -> 5.6.8-beta.1
- (no 5.6.7-beta.1 exists) -> 5.6.7-beta.2
- So, the following version transitions are OK:
- Allow creating version tags outside
mainonly if we create patches for legacy versions if newer versions require a newer macOS, in which case we'd:- Create a legacy version patch branch rooted on the version-tagged
mainrevision that is being patched. - Require that the branch be named following a convention relating it to the version tag.
- Require that all version tags on the patch branch monotonically increasing patch versions, e.g.:
- Version tag:
v1.8.6 - Patch branch:
b1.8.6(bfor branch), or possiblyp1.8.6(pfor patch), or something similar - Acceptable patch tags on
b1.8.6:v1.8.6.1-alpha.1v1.8.6.1-beta.1v1.8.6.1-beta.2v1.8.6.1v1.8.6.2- …
- Rejected tags for
p1.8.6:v1.8.5v1.8.7v1.9.0v2.0.0
- Version tag:
- Create a legacy version patch branch rooted on the version-tagged
Commits:
- Require signed commits?
- Require commit sign offs?
- Require
Resolve #…in last PR commit message? - Require
Partial #…in prior PR commit messages?
Done
- Require signed annotated tags
- Enforced by
.githubs/workflows/tag-pushed.yml. - Doesn't use
tag.gpgSign.
- Enforced by
- Disallow creating version tags outside
main.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The only implementation entry point named is .githubs/workflows/tag-pushed.yml; review it alongside the repository’s GitHub ruleset and branch-protection settings. Separate the remaining tag, branch, and commit requirements from the items marked done, then define one scoped protection and its acceptance checks; the issue does not currently identify a single change or test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github
- Domain
- devops, release, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100