Foreman 1.19.0 RC1 process

Development Releases
1

Following the branching, we want to follow the same process for RC1.

Writing release notes

  • Copy website manual content from previous version to this version (PR)
  • 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 most changes, excluding bug fixes for issues introduced during the release cycle, include link to bug numbers. You can auto-generate changes using a script from theforeman.org or use the ā€˜changelogā€™ command in tool_belt
    • CLI release notes are taken from the hammer-cli and hammer-cli-foreman changelogs
    • Link to installer changelogs and note versions being used
  • Get the apipie doc and place it in api/$release_num
    * Change links in _includes/version.html for ā€˜latestā€™ and ā€˜latest stableā€™

Preparing code

  • Request Hammer CLI releases from maintainers if desired (@cli)
  • Make patch releases of installer modules that have important changes (@ekohl)
    • 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 (@ekohl)
  • Add a new Redmine version for the next minor, unless the series is EOL
  • Remove/change release field for any open Redmine tickets assigned to the release still (next minor, unset it or reject)
  • Change Redmine version state to Closed
  • List all issues targeted at the release, order by Closed date ascending and use git cherry-pick -x to cherry pick from develop to 1.19-stable branch
  • Clone tool_belt and run:
    • ./tools.rb setup-environment configs/foreman/1.19.yaml
    • ./tools.rb cherry-picks --version 1.19.0 configs/foreman/1.19.yaml
    • Verify tickets in the cherry_picks_1.19.0 file are accounted for or additional cherry pick them

Tagging a release

  • In foreman 1.19-stable:
    • 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
    • change VERSION to 1.19.0-RC1
    • change package.json version field to 1.19.0
    • run extras/changelog
    • commit with message ā€œRelease 1.19.0-RC1ā€
  • In smart-proxy 1.19-stable commit with message ā€œRelease 1.19.0-RC1ā€:
    • change VERSION to 1.19.0-RC1
    • run extra/changelog
  • In foreman-selinux 1.19-stable commit with message ā€œRelease 1.19.0-RC1ā€:
    • change VERSION to 1.19.0-RC1
    • run extras/changelog
  • In foreman-installer 1.19-stable commit with message ā€œRelease 1.19.0-RC1ā€:
    • change VERSION to 1.19.0-RC1
  • Before tagging, make sure the test_xxxx_stable versions of each of the projects are green in Jenkins
  • Tag commits in foreman, smart-proxy, foreman-installer and foreman-selinux: git tag -s -m "Release 1.19.0-RC1" 1.19.0-RC1
  • Push to the project repos: git push project --follow-tags
  • Run the Jenkins Tarballs Release to create tarballs
  • Verify tarballs are present on downloads.theforeman.org, download, 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

2

@tbrisker there are lot of steps before the actual package building. As release manager, could you have a look if we need cherry picks? Probably donā€™t because weā€™re so close to branching.

Other than that we do need to modify our scripts to get changelogs from all the different projects because we recently switched from inherited versions to creating one per project. With @Gwmngilfen I want to look at going back to inherited versions but without the downsides.

2 Likes
3

:+1: to this, but if we canā€™t, it should be trivial to add API endpoints for what we need. Project.find(1).child_projects isnā€™t too hard to iterate over :wink:

4

Thatā€™s not really the point. A lot of these processes also search in the UI. Then you need to do that manually for 5 projects.

5

Thanks for making this visible @ekohl as it quite useful for feedback-looping on it. Some questions/thoughts for the first two sections looking now and ahead:

@akofink Wrote code to do this for Katello, I am sure it could be expanded for Core and plugins

Iā€™ve often wondered if there wold be any benefit to starting this process at start of dev cycle vs. compiling at the end.

I think we should look at doing this in the 1-2 weeks prior to branch

This should get handled by auto-releasing modules more often but wanted to call it out.

Potential to automate this more by doing it in an infra-as-code manner?

I feel like this should be switched to done by triage process?

Does this happen at branching or at GA?

6

Probably easy to do. Probably good to start syncing downstream tool_belt and upstream code, then look at adding these changes.

Iā€™d say both. If triage is up to date, then itā€™ll be pretty much a noop.

Every release is a version, that includes RCs. Technically not part of branching.

7

Iā€™m guessing most have already seen it, but for completeness, hereā€™s the proposal for reverting to inherited versions: Redmine cleanup - do we need the reporter role?

8

RC1 has now been announced - Foreman 1.19.0-RC1 has been released

9

I have left comments in the docs PR but donā€™t have time to address them. Iā€™d appreciate if anyone could take a look. Some of them must be fixed before the final release.