Foreman 3.0.0(GA) release process

Development Releases
1

Make this post a wiki

Roles

Manual updates: 2021-09-07

Release Engineer

  • 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. 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
    • 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
  • 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: 2021-09-07

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

Tagging a release: 2021-09-07

Release Owner

  • In foreman 3.0-stable:
    • Make sure test_3_0_stable is green
    • run make -C locale tx-update
    • Tag the release using tag.sh tag.sh 3.0.0 && git push upstream 3.0-stable --follow-tags
  • In smart-proxy 3.0-stable:
  • In foreman-selinux 3.0-stable:
    • Tag the release using tag.sh tag.sh 3.0.0 && git push upstream 3.0-stable --follow-tags
  • In foreman-installer 3.0-stable:
    • Tag the release using tag.sh tag.sh 3.0.0 && git push upstream 3.0-stable --follow-tags
  • Run the Jenkins Tarballs Release to create tarballs

Release Engineer

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: 2021-09-07

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

After the packages have been released

Release Owner

2

@ezr-ondrej @ekohl @upadhyeammit Posting my findings here regarding the broken release of Foreman 3.0.0. TLDR; Gem version dependency comparison strikes and breaks us at release time because Ruby treats prerelease versioning different than release versioning.

The problem we are running into is the following:

[root@pipe-foreman-server-3-0-centos8 ~]# foreman-rake db:migrate
Apipie cache enabled but not present yet. Run apipie:cache rake task to speed up API calls.
rake aborted!
ActiveRecord::DuplicateMigrationNameError: 

Multiple migrations have the name CreateEnvironments.

The reason for this is this line: https://github.com/theforeman/foreman_puppet/blob/master/lib/foreman_puppet/engine.rb#L36

Which in turn triggers the inclusion of: https://github.com/theforeman/foreman_puppet/blob/master/db/migrate_foreman/20090722141107_create_environments.rb#L1

Why did we not see this before? Well, take a look at the line in engine.rb that is conditionally including
that migration directory only if certain conditions are met. And then take a look at this output below that shows how this code is handling prerelease versions (those with a -something) in them. That is why nightly never encounters this code path and why the RCs never hit this code path.

irb(main):001:0> Gem::Dependency.new('', ">= 3.0").match?('', '3.0.0.rc2')
=> false
irb(main):002:0> Gem::Dependency.new('', ">= 3.0").match?('', '3.1.0-develop')
=> false
irb(main):003:0> Gem::Dependency.new('', ">= 3.0").match?('', '3.0.0')
=> true

I do not know what the actual solution is, given I do not have enough domain knowledge on this aspect of the Puppet plugin. But hopefully this points the experts in the right direction, explains why we are just now hitting this, and helps us think about things like this in the future.

3

I’d be in favor of a foreman_puppet 1.0.0 release which drops all conditionals on whether it was extracted or not.

4
5

I don’t think it’s a good idea at this point. but I’m not against it.
Tho I believe fixing this by https://github.com/theforeman/foreman_puppet/pull/184 would be enough and droping extracted_from_core? For the next release

6

Due to dumb things I did with RPM packaging, we really need a release of 1.0.1 to get 3.0 going and overcome RPM thinking the RC versions are a higher version than the 1.0.0 release.