Release improvements

[rgoldberg]

@phatblat
This is my WIP of improvements for the release process, plus some unrelated cleanup.

I haven't tested any of this stuff, as I'm worried about accidentally releasing a new version.

I've incorporated all your changes from your 638/release-fixes, so that can be deleted.

Can you start looking through the changes, then let me know if they're good, should be changed, or should be discarded?

The general principle of this PR is simplicity:

• Remove extraneous files from mas-cli/mas repo:
  • Makefile
  • Many bash scripts
  • Homebrew formulae: store each only in its respective tap repo, e.g., homebrew/homebrew-core or mas-cli/tap
    • Bump homebrew-core & mas-cli/tap/mas formulae in taps instead of locally generating / modifying them.
      • Do not create a manual pull request for the custom tap.
  • Generate files only when absolutely necessary, but git ignore them, e.g., Sources/mas/Package.swift
• Do not commit or branch in mas-cli/mas on release.
• Store values in as few places as possible, e.g.:
  • Store version in mas-cli/mas repo only in version tag, not in any files or in any branch names
• Reuse existing functionality (like brew bump-formula-pr) instead of reinventing the wheel
• Standardize:
  • Ensure the same tools are used everywhere, e.g.:
    • ensure /bin/bash is used everywhere instead of some places using bash from the $PATH
  • Remove dependencies whose functionality can be performed by other things, e.g.:
    • sd (script that used it was deleted, but if script kept, should use bash scripting instead)
    • mise: use brew bundle instead
• Scope code, e.g.,:
  • Formulae should be bumped only during a release, so do not perform bumps in scripts called by release workflow; instead, embed them in the workflow itself, otherwise people might incorrectly run the bump scripts outside of the workflow.
    • If, under extraordinary circumstances, someone must bump the formulae outside the release process, they should know enough about the release process to know that they should just copy the bump commands from the workflow.
• Limit pathways, prevent bad values, & make config more explicit, e.g.:
  • bash scripts should accept only arguments, not environment variables
  • Release workflows & bash scripts should:
    • Require that the release tag is a properly formatted version tag.
    • Checkout the release version tag, then use that version tag as the source for the version & for the git commit.
    • Not accept arguments, environment variables, or anything else to specify version, tag, branch, revision, etc.
• Replace script/version --write & script/version_bump with script/generate_version_info_for_swift
• When working locally, versions used (e.g. in Sources/mas/Package.swift) for revisions that aren't directly tagged with a version tag are specified by the full git describe --tags output, which includes the number of commits since the tag & the current revision.
• Cleanup release.yml job dependencies.
• bash script cleanup:
  • cd into project root at beginning of every bash script.
  • Use -u in all bash shebangs
  • Lowercase all bash non-environment variables.

Improvements that are being worked on:

• Ensure that release tag is a correctly formatted version tag.
• Why does release.yml output release event info only when name != ''?
• Dry run:
  • Specify dry run via argument to release.yml.
  • Dry run will only work with act, unless either:
    • The release workflow is manually triggered, instead of it being triggered by a release event:
      • The release process would create the release, but iff not a dry run & iff all prior steps succeeded.
    • The release workflow can retroactively cancel the release if it's a dry run or if any steps fail (probably not possible).
• mas-cli/tap/mas / GitHub Release artifacts:
  • Include version (& platform? & macOS version?) in mas.pkg filename.
  • Provide 1.8.6 bottle for macOS 10.11 & 10.12, because 1.8.7+ requires macOS 10.13+.
  • Manually generate bottles for macOS 10.13 & 10.14, because brew bump-formula-pr probably won't do that.
  • Remove bottles from custom tap that are available from homebrew-core?
  • Instead of using a single universal executable for all supported macOS versions, generate bottles for each supported platform & version of macOS?

Future tasks include:

• Cleanup actions/checkout@v4 output:
  • git config --global init.defaultBranch main
  • git config --global advice.detachedHead false
• .actrc
  • Delete?
  • Repoint --eventpath .github/event.json to a path under git-ignored .build?
• Dangerfile.swift appears to be used only for PRs made directly on mas-cli/mas, but not for those via forks:
  • Setup for fork PRs.
  • Or delete it.
• YAML & JSON schemas for validation
• Standardize file headers.
• Shell script cleanup:
  • Switch to zsh?
  • Replace commands that are not shell builtins:
    • awk
    • grep
    • ✅ cut
    • ✅ sd
    • ✅ sed
• GitHub branch & tag protections:
  • Require signed annotated tags (tag.gpgSign).
  • Disallow changing version tags.
  • Disallow creating version tags outside main except for old sub-patch version tags for branches named for the patch version.
  • Ensure that each new release 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

Resolve #638

[rgoldberg]

@phatblat I've incorporated your fixes from the 638/release-fixes branch in this repo into my branch for this PR, so you can restart using the branch from this PR.

If you have any other fixes that weren't already in that branch in this repo at the time when this comment was posted, please share them with me so I can incorporate them into the branch for this PR.

Thanks.