release automation

[markus2330]

I think we really should go for full automation (including pushing¹), even coordinating very small tasks is already very challenging as I noticed in #3535 😉

¹ My idea is that we can actually put most of the stuff in the normal pipeline (including building the packages and tar balls), maybe with a separate pipeline for things that take very long like fuzzing and #3512. Then for the actual pipeline for releases, we simply add a "dry run" option (which defaults to yes), where the result is not pushed but the logs are there for inspection.

So the release would work like this:

• version numbers get incremented
• release notes get written
• wait for master to build successfully
• trigger release pipeline with dry run
• inspect the logs&artifacts&website from the pipeline (with a predefined checklist in doc/todo/RELEASE)
• finalize release notes (we already know hash sums and so on)
• finally trigger release pipeline without dry run
• (possible) rebuilds from website for last changes in the release notes
• send out release mails&post on social media Announce Release Social Media #676

Please collect ideas now during the release, and let us decide afterwards. What do you think?

[markus2330]

I added the step "(possible) rebuilds from website for last changes in the release notes" above.

[markus2330]

Actually it is better if we make a PR modifying doc/todo/RELEASE instead of this issue and discuss there how it should be.

@robaerd can you do this already or do you need more input? We do not need to describe the details of what the pipelines do, for now it is enough if we come to an agreement about how it should be from the maintainers point of view (who does the release).

[robaerd]

Regarding "inspect the ... website from the pipeline": Do you mean that the website should also be built and deployed by the release pipeline before the actual publishing stage?

[markus2330]

I think its best if you write down your current proposal how the release should work with your pipeline (e.g. do we want the dry run option or do we want to do everything in master builds except of the publishing?)

Actually it is not a big deal that the website/release notes are modified even after the release as to some extend (like the hash sums) this is required anyway. So probably it is not required to build the website in the publishing pipeline.

[robaerd]

I think its best if you write down your current proposal how the release should work with your pipeline

I will soon push the changes to #3545 to reflect the current release workflow with the release pipeline.

Quick summary of a release with the release pipeline:

1. Release preperation (doc updates, version increments etc.)
2. Release pipeline gets triggered (dry-run option doesn't exist - was removed in favor of the input-step)
3. After all tests are run, packages and artifacts were generated and packages have been tested, the pipeline waits for input "Yes" or "Abort".
4. Download artifacts while pipeline waits for input and verify with the checklist in Release documentation #3545
5. Press "Yes" so the publishing stage is executed:
   • Pushes changes of git repos: ftp, doc, libelektra
   • Publishes all RPM and DEB packages
6. Add git statistics and hash sums to release notes.
7. Post release things (version increments, alpine image rebuilds etc.)

Actually it is not a big deal that the website/release notes are modified even after the release as to some extend (like the hash sums) this is required anyway. So probably it is not required to build the website in the publishing pipeline.

I agree, then I will not add building of the website to the release pipeline, since it will be rebuilt by the main pipeline anyway.

[markus2330]

Thank you, I am looking forward to the description in #3545. Let us close this issue then as the outdated information here is confusing us both.