Foreman 2.5 branching process

Development Releases
1

Make this post a wiki

Prep Week: 2021-04-19 to 2021-04-23

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-04-26 to 2021-04-30

Release Owner

  • Announce start of stabilization week to discourse development category.
  • Request new Hammer CLI release from maintainers if needed.
  • Prepare the manual for the new version:
    • Change $next parameter on web class to point to the new version number.
    • Copy website manual content from nightly to 2.5 and update version numbers mentioned in it.
    • Clean up deprecation and upgrade warnings from nightly manual.
  • Branch foreman-documentation git repository:

- [ ] Add new languages that are at a reasonable completion on Transifex to develop No new languages added

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/2.5.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/2.5.yaml
sed -i '/strict_keys/ s/True/False/' mash_scripts/foreman/2.5.0/foreman-plugins-2.5-*.mash
    • Open PR with new config and mash scripts for review
    • Create mash configuration on Koji, from tool_belt checkout:
      scp mash_scripts/foreman/2.5.0/*.mash root@koji.katello.org:/etc/mash/
  • Update mash script if needed - collection-mash-split.py
  • Add the new release to the JJB job definitions in foreman-infra
    • Create a 2.5.groovy in pipelines/vars/foreman/ describing the operating systems the release supports
    • Add 2.5 to the version list in theforeman.org/yaml/includes/foreman_versions.yaml.inc
    • Add 2.5 to the version list in centos.org/jobs/foreman-pipelines.yml
    • Create test_2_5_stable.yaml and test_proxy_2_5_stable.yaml in yaml/jobs/
  • Open PR to remove any jobs that are related to end of life versions
  • Open PR to add 2.5 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-05-04

Release Engineer

  • Branch RPM packaging using tool_belt
    • Clone tags and create build targets in Koji: bundle exec ./tools.rb koji --commit configs/foreman/2.5.yaml
    • Create a rpm/2.5 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-05-04

Release engineer

  • Update foreman-packaging rpm/develop to ensure nightlies build:
    • rpm/develop:
      • Update the build tag: sed -i 's/fm2_5/fm2_6/g' rel-eng/{releasers.conf,tito.props} package_manifest.yaml
      • Set to version 2.6.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 2.6-develop' foreman{,-{installer,proxy,release,selinux}} rubygem-hammer_cli{,_foreman}
    • deb/develop: scripts/changelog.rb -v 2.6.0-1 -m "Bump changelog to 2.6.0 to match VERSION" debian/*/*/changelog
  • Prepare build systems for 2.5 release:
    • foreman-packaging’s rpm/2.5
      • Update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml, rel-eng/{releasers.conf,tito.props} and repoclosure/*.conf
  • Update https://github.com/theforeman/foreman-infra/blob/master/puppet/modules/jenkins_job_builder/files/centos.org/jobs/foreman-pipeline-template.yml to expect 2.6.0-develop for nightlies

Other systems: 2021-05-04

Release Owner

  • Create release schedule page for next version (2.6) linked from Development_Resources and post planned schedule on Discourse.
  • Create Redmine versions
    • Add next version number (2.6.0) and make sure it is shared with subprojects in foreman
    • Add first patch release (2.5.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.

2

I saw this was checked but I am not seeing the announcement post. Did I overlook it?

3

Hello,

I posted the announcement one week prior to the stabilization week,

We are announcing it a week prior since few recent releases so we give heads up to the contributors. @tbrisker correct me if we need one more announcement when we start the stabilization week itself?

1 Like
4

Ahh, maybe then we change the language? Note that it falls under the week marked “Stabilization Week: 2021-4-26 to 2021-04-30” and then makes a call to action “Announce start of stabilization week”. That would imply to me that at the start of stabilization week an announcement should be sent out saying IT HAS BEGUN! So maybe a reply to that thread when the week starts to remind everyone going forward?

5

Agree, will take care of this! I think I can copy all events in discourse calendar too, maybe that will also help?

6

Most of the release work has been done, I do not understand what needs to be done for:

Update packages/foreman/foreman-release/foreman.gpg, mock/*.cfg, package_manifest.yaml, rel-eng/{releasers.conf,tito.props} and repoclosure/*.conf

and I’ve got to run at this point.

I’ve got a couple PRs that still need to be reviewed for merge:
https://github.com/theforeman/foreman-packaging/pull/6595
https://github.com/theforeman/foreman-packaging/pull/6596
https://github.com/theforeman/jenkins-jobs/pull/55

Will check back in first thing tomorrow to try and finish this part up.

7

Hello @evgeni As per the query from @zhunting like to know below details so we can add more specific details in branching process or maybe remove unwanted steps,

  • The foreman.gpg updated three years ago. Like to know when we update this as I don’t see it changing for quite long? So we can have more specific details on when to update and maybe how to update it?

  • In the mock/*.cfg I can see recent changes a month ago. Changes are to use yum.theforeman.org for content. Like to know if we touch any of the files during branching and when and why?

  • The package_manifest.yaml got updated recently however changes are not specific to branching or release. Like to know if we touch any of the files during branching and when and why?

  • @zhunting You have already updated releasers.conf and tito.props with build tags so I think there is no queries on these files?

  • The repoclosure/yum.conf recently updated to set true for repoclosure on EL8. Like to know if we touch any of the files during branching and when and why?

8

“the foreman.gpg” is slightly ambiguous.

Are you talking about foreman-packaging/foreman.gpg at rpm/develop · theforeman/foreman-packaging · GitHub?

That gets updated in stable branches only once branched.

Like this: update foreman key for 2.4 · theforeman/foreman-packaging@fd1c798 · GitHub

Documented here: tool_belt/branch.md.erb at 05123aed86fa1e8112f56c1d4468b6d5d50f7987 · theforeman/tool_belt · GitHub

We do: tool_belt/branch.md.erb at 05123aed86fa1e8112f56c1d4468b6d5d50f7987 · theforeman/tool_belt · GitHub

It’s not hugely important (we seldomly use mock to build stable stuff), but if we do it should use the right repo.

I find changes like reconfig packaging for 2.4 · theforeman/foreman-packaging@f3a912a · GitHub highly relevant for branching.

Again, same step as above: tool_belt/branch.md.erb at 05123aed86fa1e8112f56c1d4468b6d5d50f7987 · theforeman/tool_belt · GitHub

I don’t see foreman-packaging/tito.props at rpm/2.5 · theforeman/foreman-packaging · GitHub (and others) being updated, so if we build anything against 2.5 right now, it’ll land in nightly instead.

That’s still the same step: tool_belt/branch.md.erb at 05123aed86fa1e8112f56c1d4468b6d5d50f7987 · theforeman/tool_belt · GitHub
(Yes, you could argue there should be more explicit statements what needs to be changed)

Once more tool_belt/branch.md.erb at 05123aed86fa1e8112f56c1d4468b6d5d50f7987 · theforeman/tool_belt · GitHub
Repoclosure ensures that our repositories are installable by checking dependencies.
Right now 2.5 repoclosure looks at nightly repos, which is wrong.

1 Like