Create tagged releases for stable branches #66
Comments
|
We discussed this in today's community meeting and folks seemed open to the idea. @mattclay, is this something you'd be willing to have in https://github.com/ansible/ansible/blob/devel/packaging/release.py or otherwise integrated into core's release process? |
|
Since the documentation and core releases aren't exactly synchronized, I'm not sure it's a great idea to give that appearance by adding matching tags. However, if tags are desired, you should be able to set up automation (perhaps GitHub Actions) to monitor the GH releases for ansible-core and create matching tags as new releases show up. |
|
Yes, these tags are desired (at least by me they are :). The goal here is to simply record the state of this repository after each ansible-core release. For now, I guess I can push the tags manually, and I'll think of a better long term solution. Whatever the case, I'd much prefer a "push model" than a "pull model". |
|
From the Ansible build perspective, having ansible-core releases tagged here as well is very important since otherwise it is impossible to properly and reproducably build the porting guide for Ansible. |
|
What's the next step here? We have ...2.5 weeks before this becomes another manual tagging effort for the next core release... |
|
We need tagged releases in order to properly retrieve ansible-core porting guides in a reproducible fashion when creating the ansible combined porting guide. Currently, we retrieve the latest file from the devel branch (https://raw.githubusercontent.com/ansible/ansible-documentation/devel/docs/docsite/rst/porting_guides/porting_guide_core_{MAJOR_VERSION}.rst) which is wrong. We should be retrieving the porting guide from the time an ansible release's respective ansible-core version was actually released (https://raw.githubusercontent.com/ansible/ansible-documentation/v{VERSION}/docs/docsite/rst/porting_guides/porting_guide_core_{MAJOR_VERSION}.rst). We discussed this in ansible-community/antsibull-build#540. I'd like to make this change but cannot until we can rely on these tags existing. I also need these tags for the Fedora ansible-core package. If the core team doesn't want to own this, I can keep doing it manually. |
|
on the porting guide - frequently, the porting guide PRs get merged AFTER a release has happened. Historically, we haven't held up any release to pypi because a porting guide PR hasn't been merged, backported, merged, and published. |
|
I'm talking about needing the tags for core porting guides. The combined porting guides that are created as part of the |
|
By the way, https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/ansible/tag.py is the script I've been using to create these tags. It makes some assumptions about how I set up my git clones, so it may be destructive/do the wrong thing if you have a different setup. At some point, I'll clean it up (i.e. make it more general and error resistant) and it to the |
|
@gotmax23 thanks for doing this manually... @mattclay 's #66 (comment) makes it sounds like we can automate this somehow? Or is the only automation option for these tags have to be in ansible/ansible directly? |
|
It would be less error prone if the automation was in ansible/ansible. It's nice that the tags are signed with my trusted GPG signature when I do it manually, but it'd also be nice not to be the single point of failure. |
|
It can be automated, but the automation doesn't need to live in the ansible/ansible repository. |
|
It would be much easier to write an automation that happens during the core release process instead of something elsewhere that has to poll for new core releases. |
|
|
|
I merged #1084 which has the script I use to create the tags. Next up, I'd like to prepare Github Actions automation to handle do this automatically. |
|
ooch... we haven't been remembering to update this issue with tagging commits... @gotmax23 do we need to go back and and add the ones missing since mid-march? |
|
I think it's OK to not mention all the tags here, as long as we make sure that the tagging happens :) |
github-project-automation
bot
moved this from 🏗 In progress
to ✅ Done
in Ansible Documentation
Would it be possible to tag the current state of a
stable-2.Xbranch after each ansible-core release? I understand that the plan is to separate the deployment of docs from ansible-core releases, but this would be helpful for distributions that provide docs and want to sync them with core releases1. Also, I think this will be helpful for upstream purposes so it's easier to see how docs change overtime when looking back at the git history.Footnotes
Currently, Fedora does not build the html docs, but we do include the raw rst files in an ansible-core-doc subpackage, and I'd prefer not to remove that package in the middle of a release. ↩
The text was updated successfully, but these errors were encountered: