Automated release

[benthomasson]

This PR creates an automated release process using github actions and an ansible rulebook.

This can also be run locally using this command:

ansible-playbook tools/ansible/release.yml -i localhost -e github_token=${GH_TOKEN}

An example release is here: https://github.com/ansible/ansible-rulebook/releases/tag/2024.2.22

[mkanoor]

@benthomasson Would this get published to PyPi at the end?

[benthomasson]

@benthomasson Would this get published to PyPi at the end?

Yes, we probably should. I'll do that in another PR.

[mkanoor]

@benthomasson Would switching from semver to calver have issues if there are users using versions in their requirements.txt files or Dockerfiles?

[benthomasson]

@benthomasson Would switching from semver to calver have issues if there are users using versions in their requirements.txt files or Dockerfiles?

The calver will be greater than semver, so going that way won't be a problem.

[mkanoor]

@benthomasson Should the release document that we are switching to CalVer?

[Alex-Izquierdo]

The main goal of this automation is the automatic publication of the package in pypi. That step would be even more complicated with this pipeline, because with the current manual procedure we can generate the artifacts and publish them in pypi with the same command but now we should download the artifacts generated by this pipeline and publish them manually. I recommend to add that step before merge.

[benthomasson]

The main goal of this automation is the automatic publication of the package in pypi. That step would be even more complicated with this pipeline, because with the current manual procedure we can generate the artifacts and publish them in pypi with the same command but now we should download the artifacts generated by this pipeline and publish them manually. I recommend to add that step before merge.

We should not be building any released binary locally. It is very easy to slip in development files into a release build without realizing it if it is built locally.

[Alex-Izquierdo]

We should not be building any released binary locally. It is very easy to slip in development files into a release build without realizing it if it is built locally.

The local build/publish is already handled by make: https://github.com/ansible/ansible-rulebook/blob/main/Makefile#L80

My point is that the publication on pypi is the main goal of an automated release process. Users usually won't consume the artifacts from github, they will run pip install ansible-rulebook as it is described in the documentation.

With the current process you only have to run make. Now, with this pipeline as it is now, I should have to go to github, download the artifacts generated and publish them in pypi, which is a more tedious process than make release

That's why I'm requesting to automate also the publication on pypi.

[Alex-Izquierdo]

As it is now, the release could be done accidentally with the code of any branch. I think it would be good to ensure that only can be executed from the expected branches.

[Alex-Izquierdo]

Can you add if: github.repository == 'ansible/ansible-rulebook' to make clear this workflow is not intended to be executed by forks?

[benthomasson]

It doesn't work on forks because it doesn't have permissions to push to this repo.

[Alex-Izquierdo]

I think calver doesn't meet our requirements. We have to maintain multiple versions right now are two:
main and https://github.com/ansible/ansible-rulebook/tree/stable/1.0

Eventually we will have to maintain more versions. The calver itself doesn't tell you what is the branch. Everytime you need to check the releases for a given supported version you would have to inspect the tags per branch.

If a user wants the latest release of 1.0, we are forcing him to figure out first what is the tag and we prevent him to set rules like (<=1.0.*)

[benthomasson]

I think calver doesn't meet our requirements.

This is a valid concern. I am debating this myself. With semver we need to be able to bump the patch number every week to do automated weekly releases. That might make the patch number meaningless. https://semver.org/spec/v2.0.0.html. Semver 2.0 does support release candidates so that should be easier to automate.

[benthomasson]

I am closing this in favor of #667