Foreman 3.4.0(GA) release process

[upadhyeammit]

Make this post a wiki

Roles

• Release Owner: @upadhyeammit
• Release Engineer: @pcreech
• Installer Maintainer: @ekohl

Manual updates: 2022-09-08

Release Owner

• 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.
    • For theforeman.org: You can auto-generate changes using the release notes script.
    • For docs.theforeman.org: You can auto-generate changes using redmine_release_notes script, more details are available in README.
  • Append CLI release notes taken from the hammer-cli and hammer-cli-foreman changelogs, in theforeman.org and docs.theforeman.org websites release notes.
  • Headline features: half a dozen important features with a few sentences description each
  • Upgrade notes on theforeman.org and docs.theforeman.org: 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 docs and raise pull request in apidocs repository

Preparing code: 2022-09-08

Installer Maintainer

• 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

Release Owner

• Remove/change target version 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 3.4.0 in redmine. issues.rb can be used to generate a comparison between the two.
• Change Redmine version 3.4.0 state to Closed

Tagging a release: 2022-09-08

Release Owner

• In foreman 3.4-stable:
  • Make sure test_3_4_stable is green
  • run make -C locale tx-update Now new updates!
  • Tag the release using tag.sh tag.sh 3.4.0 && git push upstream 3.4-stable --follow-tags
• In smart-proxy 3.4-stable:
  • Make sure test_proxy_3_4_stable is green
  • Tag the release using tag.sh tag.sh 3.4.0 && git push upstream 3.4-stable --follow-tags
• In foreman-selinux 3.4-stable:
  • Tag the release using tag.sh tag.sh 3.4.0 && git push upstream 3.4-stable --follow-tags
• In foreman-installer 3.4-stable:
  • Tag the release using tag.sh tag.sh 3.4.0 && git push upstream 3.4-stable --follow-tags
• Run the Jenkins Tarballs Release to create tarballs

Release Engineer

• 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: 2022-09-08

Note it is considered good practice to release on a day when the next day is a working day. This means no releases on Fridays or on the day before a holiday.

Release Engineer

Background documentation

• Update foreman-packaging branches
  • rpm/3.4
  • deb/3.4
• Wait for packages to be built
  • rpm/3.4
  • deb/3.4
• Tag foreman-release into foreman-client-3.4-rhel7 and foreman-client-3.4-el8, as this doesn’t happen automatically for those tags.
  • koji tag-build foreman-client-3.4-rhel7 foreman-release-3.4.0-1.el7
  • koji tag-build foreman-client-3.4-el8 foreman-release-3.4.0-1.el8
• Tag yggdrasil into foreman-plugins-3.4-nonscl-rhel7 and foreman-plugins-3.4-el8, as this doesn’t happen automatically for those tags.
  • koji tag-build foreman-plugins-3.4-el8 yggdrasil-VERSION.el8
• Check for outstanding PRs against 3.4 packaging, and merge if possible:
  • rpm/3.4
  • deb/3.4
• 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

After the packages have been released

Release Owner

• Update the versions on the website in version and latest news

• Update the foreman_version to 3.4 in website’s _config.yml file

• Update the docs.theforeman.org index page and versions,

  • Update 3.4 as supported
  • Update 3.2 as unsupported

• Announce the release on Discourse

• Update the topic in #theforeman channel on Freenode

• Share the release announcement on twitter

• After about a week, update stable version in foreman-infra

• Release pipeline will trigger foreman-plugins-3.4-deb-test-pipeline and foreman-plugins-3.4-rpm-test-pipeline. These don’t block releases but can be used to understand known issues around plugin compatibility with Foreman 3.4.