Foreman 3.1 branching process

Make this post a wiki


Prep Week: 2021-10-18 to 2021-10-22

Installer Maintainer

Release Owner

  • Ensure headline features planned for the release have been merged or push them off to the next release.
  • Translations:

Stabilization Week: 2021-10-25 to 2021-10-29

Stabilization Week: 2021-11-01 to 2021-11-05

Release Owner

Release Engineer

  • Create new GPG key for release. See GPG_Keys if needed.
  • Publish the key by exporting the GPG key
  • Create new settings files for client, ensure it has the rights OSES list and commit it too.
  • Create configs/foreman/3.1.yaml based on the nightly and previous release. Ensure that any based_on entries are filled out and pointing to nightly version of tag.
    • Generate mash configs
      bundle exec ./tools.rb mash-scripts configs/foreman/3.1.yaml
      sed -i '/strict_keys/ s/True/False/' mash_scripts/foreman/3.1.0/foreman-plugins-3.1-*.mash
    • Open PR with new config and mash scripts for review
    • Create mash configuration on Koji, from tool_belt checkout:
      scp mash_scripts/foreman/3.1.0/*.mash
  • Update mash script if needed -
  • Add the new release to the JJB job definitions in jenkins-jobs
    • Create a 3.1.groovy in pipelines/vars/foreman/ describing the operating systems the release supports
    • Add 3.1 to the version list in
    • Add 3.1 to the version list in
    • Create test_3_1_stable.yaml and test_proxy_3_1_stable.yaml in yaml/jobs/
  • Open PR to remove any jobs that are related to end of life versions
  • Open PR to add 3.1 to Forklift versions config. Once the PR is merged, upgrade pipelines will fail, so do not merge it before packaging has been branched.

Branching: 2021-11-02

Branching: 2021-11-09

Release Engineer

  • Branch RPM packaging using tool_belt
    • Clone tags and create build targets in Koji: bundle exec ./tools.rb koji --commit configs/foreman/3.1.yaml
    • Create a rpm/3.1 branch in foreman-packaging based on rpm/develop
  • Branch Debian packaging

Release Owner

The next step should only be done after all branching, including packaging, has completed.

Preparing build systems: 2021-11-09

Preparing build systems: 2021-11-09

Release engineer

  • Update foreman-packaging rpm/develop to ensure nightlies build:
    • rpm/develop:
      • Update the build tag: sed -i 's/fm3_1/fm3_2/g' rel-eng/{releasers.conf,tito.props} package_manifest.yaml
      • Set to version 3.2.0, reset release to 1 in packages/foreman/foreman{,-{installer,proxy,release,selinux}}/*.spec and packages/foreman/rubygem-hammer_cli{,_foreman}/*.spec. Then create a changelog using obal changelog --message '- Bump version to 3.2-develop' foreman{,-{installer,proxy,release,selinux}} rubygem-hammer_cli{,_foreman}
    • deb/develop: scripts/changelog.rb -v 3.2.0-1 -m "Bump changelog to 3.2.0 to match VERSION" debian/*/*/changelog
  • Prepare build systems for 3.1 release:
    • foreman-packaging’s rpm/3.1
      • Update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml, rel-eng/{releasers.conf,tito.props} and repoclosure/*.conf
  • Trigger the foreman-packaging-rpm-3.1 job once, so that GitHub hooks are properly set up.

Other systems: 2021-11-02

Other systems: 2021-11-09

Release Owner

  • Create release schedule page for next version (3.2) linked from Development_Resources and post planned schedule on Discourse.
  • Create Redmine versions
    • Add next version number (3.2.0) and make sure it is shared with subprojects in foreman
    • Add first patch release (3.1.1) and make sure it is shared with subprojects in foreman
  • Ensure current Foreman deprecations for the next release are removed in develop

This was based on the wiki procedure and sometimes has a bit more info.

For this steps, where or when it’s expected for all tarballs to be created and published at{packages}? We don’t have the tag develop on GH for these projects.

Even after the bump in these projects for 3.2, the tarball was not created.