Foreman 1.23.0-RC1 release process

Writing release notes

  • Update manual if applicable for any additional installation steps
  • Draft release notes in markdown (example), with these sections (and do not use personal pronouns):
    • 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
    • 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
    • Update installer options section using the get-params script
  • Get the apipie doc and place it in api by following https://github.com/theforeman/theforeman.org#updating-api-auto-generated-docs-by-apipie

Preparing code

  • Request Hammer CLI releases from maintainers if desired
  • 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 Target Version field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
  • Clone tool_belt and run:
    • ./tools.rb setup-environment configs/foreman/1.23.yaml
    • ./tools.rb cherry-picks --version 1.23.0-RC1 configs/foreman/1.23.yaml
    • Verify tickets in the cherry_picks_1.23.0-RC1 file are accounted for or additional cherry pick them

Tagging a release

  • In foreman 1.23-stable:
    • Make sure test_1_23_stable is green
    • run make -C locale tx-update (if Transifex has not switched to the next major release yet, usually after .2)
    • run script/sync_templates.sh
    • update template snapshots with rake snapshots:generate RAILS_ENV=test and verify changes are expected
    • change VERSION to 1.23.0-RC1
    • Run extras/changelog
    • Commit: git commit -am "Release 1.23.0-RC1"
    • Tag: git tag -s -m "Release 1.23.0-RC1" 1.23.0-RC1
    • Push: git push --follow-tags
  • In smart-proxy 1.23-stable:
    • Make sure test_proxy_1_23_stable is green
    • change VERSION to 1.23.0-RC1
    • Run extra/changelog
    • Commit: git commit -am "Release 1.23.0-RC1"
    • Tag: git tag -s -m "Release 1.23.0-RC1" 1.23.0-RC1
    • Push: git push --follow-tags
  • In foreman-selinux 1.23-stable:
    • change VERSION to 1.23.0-RC1
    • Run extras/changelog
    • Commit: git commit -am "Release 1.23.0-RC1"
    • Tag: git tag -s -m "Release 1.23.0-RC1" 1.23.0-RC1
    • Push: git push --follow-tags
  • In foreman-installer 1.23-stable:
    • change VERSION to 1.23.0-RC1
    • Commit: git commit -am "Release 1.23.0-RC1"
    • Tag: git tag -s -m "Release 1.23.0-RC1" 1.23.0-RC1
    • Push: git push --follow-tags
  • Run the Jenkins Tarballs Release to create 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

I opened packaging PR, but these will most likely fail on repoclosure.


Going to sign the first batch of RPMs and do an initial sync.

Some notes while doing the process:

  • ARM builds failed to push push the builds. Need to check the SSH key(s)
  • Started the new job release pipeline (https://ci.theforeman.org/job/foreman-1.23-release-pipeline/1/) anyway to see if that works while I figure out the ARM builds
  • CentOS7 release pipeline failed because I didn’t push the foreman-rails-1.23 repo to its final location.
1 Like

It’s also installing the client repository but that’s failing because I didn’t sync after release_packages. We should wonder if this should even be enabled in this tests since Foreman should install without the client repos. Having them enabled could create an unintended dependency. Arguably this also goes for the plugins repo. For now I synced the client repo.