Foreman 2.2.0-rc1 release process

[upadhyeammit]

Make this post a wiki

Manual updates

• Update manual if applicable for any additional installation steps
• Update release notes section in the manual:
  • Release notes: bullet point list by category of all changes, include link to bug numbers. You can auto-generate changes using the release notes script.
  • CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
  • Link to installer changelogs and note versions being used
  • Headline features: half a dozen important features with a few sentences description each
  • Upgrade notes: all important notices that users must be aware of before upgrading
• Update installer options section using the get-params script (Note: this step can only be done after packages are released)
• Generate the apipie doc and place it in the api/2.2 directory

Preparing code

• Make patch releases of installer modules that have important changes
  • Branch to MAJ.MIN-stable if recent changes to the module aren’t suitable for patch (x.y.z) release
• Compare tagged packages in nightly vs. release koji tag and re-tag any updated dependencies that are required
• Remove/change release field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
• Ensure that code in git matches issues fixed in 2.2.0-rc1 in redmine. issues.rb can be used to generate a comparison between the two.

Tagging a release

• In foreman 2.2-stable:
  • Make sure test_2_2_stable is green
  • run make -C locale tx-update (if Transifex has not switched to the next major release yet, usually after .2)
  • Tag the release using tag.sh tag.sh 2.2.0-rc1
  • Push: git push upstream 2.2-stable --follow-tags
• In smart-proxy 2.2-stable:
  • Make sure test_proxy_2_2_stable is green
  • Tag the release using tag.sh tag.sh 2.2.0-rc1
  • Push: git push upstream 2.2-stable --follow-tags
• In foreman-selinux 2.2-stable:
  • Tag the release using tag.sh tag.sh 2.2.0-rc1
  • Push: git push upstream 2.2-stable --follow-tags
• In foreman-installer 2.2-stable:
  • Tag the release using tag.sh tag.sh 2.2.0-rc1
  • Push: git push upstream 2.2-stable --follow-tags
• Run the Jenkins Tarballs Release to create tarballs
• Update release version similar to here
• Sign Tarballs
  • Download
  • Inspect
  • Sign and upload detached signatures

Note: If for some reason there was an issue with the tarballs that required uploading new tarballs, CDN cache should be invalidated so that the builders use the updated tarballs.

Packaging a release

Background documentation

• Update foreman-packaging
  • rpm/2.2
  • deb/2.2 branches
• Trigger release_packages in Jenkins by calling release_packages script.
• Tag foreman-release into foreman-client-2.2-rhel7 and foreman-client-2.2-el8, as this doesn’t happen automatically for those tags. Make sure the build matches the release.
  • koji tag-build foreman-client-2.2-rhel7 foreman-release-2.2.0-1.el7
  • koji tag-build foreman-client-2.2-el8 foreman-release-2.2.0-1.el8
• Sign the RPMs in the release
  • Download
  • Sign
  • Upload RPM signatures
  • Upload RPMs
• Sign RPMs for client repos (call scripts with PROJECT=client)
  • Download
  • Sign
  • Upload RPM signatures
  • Upload RPMs
• Kick off the release pipeline by calling release_pipeline
• Kick off the client pipeline by calling PROJECT=client release_pipeline
• Kick off the plugins pipeline by calling plugins_pipeline

[ehelms]

2.2.0-rc1 RPMs are all officially released. Some after action notes for future updates:

1. I had to re-run the release pipeline due to our procedure missing notes on handling hammer completely. I will send along updates to capture what I saw.
2. With the amount of OSes and upgrades we now test, we almost always see 1-2 fail on provisioning a node from ci.centos.org. This could be due to quota or too many parallel operations. To try to help with this I opened PR to have it retry if it fails.