You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
autopub prepare: Increment version number, append to CHANGELOG, etc.
autopub build: Build the package
autopub commit: git commit the changes from the first step
autopub githubrelease: git tag and publish release to GitHub (single step)
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:
autopub prepare: Increment version number, append to CHANGELOG, etc.
autopub commit: git commit the changes from the first step
autopub tag: git tag the above commit, with tag as return value
autopub build: Build the package
autopub githubrelease --tag 4.9: Pass tag return value to GitHub release function
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.)
The text was updated successfully, but these errors were encountered:
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:
Current Flow
The current flow looks something like:
autopub prepare
: Increment version number, append to CHANGELOG, etc.autopub build
: Build the packageautopub commit
:git commit
the changes from the first stepautopub githubrelease
:git tag
and publish release to GitHub (single step)autopub publish
: Publish package to PyPIThe 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 commandautopub tag
, then an alternative flow supporting the above use case could look something like:autopub prepare
: Increment version number, append to CHANGELOG, etc.autopub commit
:git commit
the changes from the first stepautopub tag
:git tag
the above commit, with tag as return valueautopub build
: Build the packageautopub githubrelease --tag 4.9
: Pass tag return value to GitHub release functionautopub publish
: Publish package to PyPI(If no
--tag
flag is passed toautopub 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 expectautopub githubrelease
to do what it currently does.)The text was updated successfully, but these errors were encountered: