Create tagged releases for stable branches

gotmax23 commented 1 year ago

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.

gotmax23 commented 1 year ago

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?

mattclay commented 1 year ago

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.

gotmax23 commented 1 year ago

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".

felixfontein commented 1 year ago

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.

gotmax23 commented 1 year ago

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

samccann commented 1 year ago

What's the next step here? We have ...2.5 weeks before this becomes another manual tagging effort for the next core release...

gotmax23 commented 1 year ago

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.

samccann commented 1 year ago

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.

gotmax23 commented 1 year ago

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.

gotmax23 commented 12 months ago

gotmax23 commented 11 months ago

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.

gotmax23 commented 11 months ago