Make a Git tag when doing a new release

[nox]

Tags is the only thing that can tell whether a commit is part of a given release from the GitHub UI.

[briansmith]

Good idea.

I think that this can be automated by putting it in the mk/package.sh script, which I always run prior to doing cargo publish --allow-dirty. Note that the mk/package.sh script only runs in MinGW (on Windows).

[briansmith]

I manually created a tag for the 0.7.0 release. I haven't tried to automate the tagging yet.

[briansmith]

In general I've been doing this. It would be better if I automated it, but I'm going to close this since the manual step seems to be working well enough. Thanks for the suggestion.

[briansmith]

Here are the exact steps I did for the 0.17.6 release, copied from #1460 (comment):

# Start Windows machine, open a "Git Bash" prompt, and change to my *ring* checkout directory.
$ git checkout main
$ git checkout -b b/0.17.6
# Change `version = "0.17.6"` and `links = "ring_core_0_17_6"` in Cargo.toml.
$ git commit -m "0.17.6."
$ git push -u
# Create the "0.17.6." pull request in the GitHub UI. TODO: automate using `gh`
# Wait for all the CI jobs to pass.
$ mk/package.sh
$ cargo publish --allow-dirty
$ rm -Rf pregenerated

[nazar-pc]

I see above comments say that something was tagged in the past, maybe tags were never pushed to the repo then?
Right now there are none visible: https://github.com/briansmith/ring/tags

Also --allow-dirty is a bad sign. Either files are in the repo (in which case --allow-dirty should not be needed) or they are not, but should be added (such that --allow-dirty is no longer necessary). Otherwise whatever is published on crates.io will never match the contents of the repository, which is bad for code auditing.

I see mk/package.sh generates some files, which makes the repo dirty during publishing. What I'd probably do is commit those files to Git and add GitHub Actions workflow checking that they match the source code on each PR.

[briansmith]

@nazar-pc Many, many people have suggested that. If I wanted it done that way, it would already be done.

If we're lucky somebody will write a script for the above that helps automate the publishing process, and then we can add a git tag step into that script.

[briansmith]

https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise