ansible-documentation
ansible-documentation copied to clipboard
ansible
Create tagged releases for stable branches
Would it be possible to tag the current state of a stable-2.X branch 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 releases[^1]. 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.
[^1]: 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.
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.
For now, I guess I can push the tags manually
https://github.com/ansible/ansible-documentation/releases/tag/v2.15.2 https://github.com/ansible/ansible-documentation/releases/tag/v2.14.8 https://github.com/ansible/ansible-documentation/releases/tag/v2.13.11
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 https://github.com/ansible-community/antsibull/pull/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 ansible package build process are indeed created after the release.
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.9rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.3rc1
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 hacking folder in this repo.
- https://github.com/ansible/ansible-documentation/releases/tag/v2.13.12rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.10rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.4rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.13.12
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.10
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.4
@gotmax23 thanks for doing this manually... @mattclay 's https://github.com/ansible/ansible-documentation/issues/66#issuecomment-1633284160 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.
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.11rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.5rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.16.0b2
- https://github.com/ansible/ansible-documentation/releases/tag/v2.13.13
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.11
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.5
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.12rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.7rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.16.1rc1
- https://github.com/ansible/ansible-documentation/releases/tag/v2.14.12
- https://github.com/ansible/ansible-documentation/releases/tag/v2.15.7
- https://github.com/ansible/ansible-documentation/releases/tag/v2.16.1
- Tagging 37177dce6911b821d671f5c8133c95b71fdffd88 as v2.14.13 Pushing v2.14.13 to origin
- Tagging 78d3d504f6990e7474f8f1a2724d1f464d6fb2bc as v2.15.8 Pushing v2.15.8 to origin
- Tagging 0951548407d87f00393491c8c6797a06e50b2f09 as v2.16.2 Pushing v2.16.2 to origin
- Tagging de91530883ce082bab8aa8799103235b4f9c8354 as v2.14.14rc1 Pushing v2.14.14rc1 to origin
- Tagging 851b232f89457f2d27ad17f698ee1960a27477fd as v2.15.9rc1 Pushing v2.15.9rc1 to origin
- Tagging b0ae01a4dfb06a793eb6ec38d12ddd508a767b28 as v2.16.3rc1 Pushing v2.16.3rc1 to origin
- Tagging de91530883ce082bab8aa8799103235b4f9c8354 as v2.14.14 Pushing v2.14.14 to origin
- Tagging d84cc4c5db9c87ce4d1e3af7cd0491f6fb4d3622 as v2.15.9 Pushing v2.15.9 to origin
- Tagging 4d376f77b26fb99073d7e50554429b917549b780 as v2.16.3 Pushing v2.16.3 to origin