De-couple commit tagging from GitHub release function

[justinmayer]

Current Flow

The current flow looks something like:

1. autopub prepare: Increment version number, append to CHANGELOG, etc.
2. autopub build: Build the package
3. autopub commit: git commit the changes from the first step
4. autopub githubrelease: git tag and publish release to GitHub (single step)
5. autopub publish: Publish package to PyPI

The reason for this order is that the autopub githubrelease step needs both the built package as well as the Git tag.

Issue

Let's say you want to build the package after the commit has been tagged. Since the package must be built before it is handed to GitHub release process, there is currently no easy way to do things in this order in an AutoPub context because the autopub githubrelease step performs both tagging and releasing in a single step.

Proposal

If the git tag step were to be moved into a separate function, along with a corresponding new command autopub tag, then an alternative flow supporting the above use case could look something like:

1. autopub prepare: Increment version number, append to CHANGELOG, etc.
2. autopub commit: git commit the changes from the first step
3. autopub tag: git tag the above commit, with tag as return value
4. autopub build: Build the package
5. autopub githubrelease --tag 4.9: Pass tag return value to GitHub release function
6. autopub publish: Publish package to PyPI

(If no --tag flag is passed to autopub githubrelease, then that step would continue to function as before, with tag+release performed in a single step, for backwards compatibility for folks who currently expect autopub githubrelease to do what it currently does.)

[apollo13]

Hi Justin, yes I think that this would be an improvement to some extend, but on the other hand it will make things more complicated as well.

Some rough thoughts (not necessarily on autopub or kagi itself, but just so you see where I am coming from):

• The CI systems that I know (Github and Gitlab) don't really like you to have a job commit to the repo and then trigger new CI events on that. One generally has to do "workarounds" for that…

• Assuming one can prepare everything locally, one is required to either push the tag & code directly to main or make a PR/MR and push the tag only after the code has been merged (otherwise you are releasing code that might not even be in main yet). I personally would very much like to prevent direct pushes to main, but I do not have a good answer for the tagging situation here.

• No matter what is done, the binaries that are created and uploaded should be the same bit for bit (ie github release vs pypi release). While not required with reproducible builds it would still be preferable to have them come from the same job.

• Maintainer time is limited always, do one want to maintain an extra tool or is there something out there that is maintained & reusable.

• With regard to the proposal directly: It is not exactly clear when the tags and commits are pushed? I think the commits will get pushed as part of autopub commit and the tag as part of autopub tag?

• I do not think that you will need --tag to autopub githubrelease because if the tag already exists it will happily operate on that:

  autopub/autopub/create_github_release.py

  Line 39 in 8d41aed

  if not tag_exists: