Foreman 2.0 branching process

Development Releases
1

Make this post a wiki

Two weeks before branching

During the week before branching

Package build systems

  • Create tool_belt config based on the previous release PR

  • Clone tags and create build targets in Koji: bundle exec ./tools.rb koji --commit configs/foreman/2.0.yaml

  • Make sure all nightly builds of packages are removed from the releases tags

  • Create mash configuration on Koji:

    bundle exec ./tools.rb mash-scripts configs/foreman/2.0.yaml
sed -i '/strict_keys/ s/True/False/' mash_scripts/foreman/2.0.0/foreman-plugins-2.0-*.mash
scp mash_scripts/foreman/2.0.0/*.mash root@koji.katello.org:/etc/mash/

  • Update mash scripts and deploy them to Koji:

    • Verify main mash scripts (foreman-mash-split.py, foreman-rails-mash-split.py and foreman-plugin-mash-split.py) don’t need any version-specific updates
    • Update dists in client mash script (foreman-client-mash-split.py)

  • Add version 2.0 to jobs in axes and/or combination filters, remove old ones (keep three)

  • Clone Debian nightly repos to 2.0 using copy/freight instructions

Branch main code repos

  • Create 2.0-stable branches
  • Branch foreman-packaging
    • Create rpm/2.0 and update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml, rel-eng/{releasers.conf,tito.props} and repoclosure/*.conf PR
    • Create deb/2.0
    • Update .github/PULL_REQUEST_TEMPLATE.md (by adding [ ] 2.0 to it) in master
  • Bump versions to 2.1-develop
    echo 2.1.0-develop > VERSION
  • Update foreman-packaging to 2.1:
    • rpm/develop:
      • Update the build tag: sed -i 's/fm2_0/fm2_1/g' rel-eng/{releasers.conf,tito.props} PR
      • Set to version 2.1.0, reset release to 1 in packages/foreman/foreman{,-{installer,proxy,release,selinux}}/*.spec and create a changelog using obal changelog --message '- Bump version to 2.1-develop' foreman{,-{installer,proxy,release,selinux}} PR
    • deb/develop: scripts/changelog.rb -v 2.1.0-1 -m "Bump changelog to 2.1.0 to match VERSION" debian/*/*/changelog

Other systems

  • Create release schedule page for next version (2.1) linked from Development_Resources and post planned schedule on Discourse.
  • Create Redmine versions
    • Add next version number (2.1) and make sure it is shared with subprojects in foreman
    • Add first patch release (2.0.1) and make sure it is shared with subprojects in foreman
  • Add the new release to the JJB job definitions in foreman-infra
    • Create a 2.0.groovy in pipelines/vars/foreman/ describing the operating systems the release supports
    • Add 2.0 to the version list in yaml/jobs/pipeline/foreman-release.yaml
    • Create test_2_0_stable.yaml and test_proxy_2_0_stable.yaml in yaml/jobs/
    • Remove the oldest version to keep last 3 from the files/directories in the previous steps
  • Ensure current Foreman deprecations for the next release are removed in develop
  • Add 2.0 to Forklift versions config

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

1 Like
2

All the Puppet modules have been released and kicked off https://ci.theforeman.org/job/foreman-installer-develop-source-release/321/

Some complications we are seeing is that both Katello (https://github.com/Katello/katello/commit/ead2d60c9045e8a2687b7bb41c8a0473bb090ff4) and hammer-cli-foreman (https://github.com/theforeman/hammer-cli-foreman/commit/2f77410d6cbea4d2af450d4a6f587937930d9bc0) have been bumped to the new version before packaging was branched. Since they have nightly packages, that is a problem. Our tooling assumes they match and currently the release jobs are failing. In the future we should make sure this doesn’t happen again.