Katello 4.8 branching process

Development Releases
1

Hello community,

We’re less than 1 month out from the targeted Foreman 3.6 branching date, and hence the Katello 4.8 branching date as well. I’ve posted the Katello 4.8 branching process below.

  • Release Owner: @cintri84
  • Release Engineer: @zhunting

One Month Prior to Branch Date

Release Owner

  • Start attending upstream release sync meetings and giving updates
  • Announce upcoming branching to Discourse development category a month before
  • Update Katello Transife translations:
    • Create a Transife account and join the Foreman team
    • Spin up a Foreman and Katello installation
    • Configure the Transife client
    • Install grunt
    • grunt i18n:extract in the katello/engines/bastion_katello directory
    • make -C locale tx-update in the katello directory
    • grunt i18n:compile in the katello/engines/bastion_katello directory
    • bundle exec rake plugin:gettet[katello] in the foreman directory
    • make -C locale mo-files in the katello directory
    • Commit the resulting files in the katello directory with a message like “i18n - pulling from tx”
    • Open a PR to Katello (no Redmine issue needed)

Three Weeks Prior to Branch Date

Release Owner

  • Ensure that issues requiring installer changes are merged

Two Weeks Prior to Branch Date

Release Owner

  • Add tool_belt config for new release:
    • Create a new yaml file using the nightly Katello config as a template: tool_belt configs
    • Manually update the following sections:
      • releases: update to current release. Move the previous ‘current’ release to prior releases below.
      • prior releases: Remove the oldest prior_release (check with that release owner first to see if there’s a reason it should stay)
      • mash scripts: update Katello version number in all values
      • repos: Update branch names to current versions, including any new releases that need to happen
      • ignores: Delete all items from this list and start fresh (this will be used for cherry-picks later)
      • gpg-key: When it becomes available, get the new Foreman GPG key for the corresponding Foreman version (eample here and put the last 8 characters here
      • tags: update Katello version number in all values. Check the nightly config to see if any tags/repos need to be updated
    • Open a PR to tool_belt with the new config file
  • Ensure stable Pulp release
  • Coordinate with installer maintainers that expected changes are completed.
  • Create PRs to Jenkins-jobs to add a mapping between the current Foreman and Katello release branches and update pipelines. See this test mapping PR eample and this pipeline PR eample.
  • Files to edit: testKatello.groovy, katello-pipelines.yml, and katello-rpm-pipeline.yaml.
  • Review the Foreman schedule and planning (eample) and note the date of the first scheduled release candidate.

Release Engineer

  • Ensure tool_belt config is merged and output from ./tools.rb koji configs/katello/48.yaml matches epectations

On Branch Date

Release Owner

  • Create KATELLO-4.8 branches
  • Bump versions to 4.9-master
  • Bump Katello related packages to their 4.9 versions
  • Generate and post the release procedure, if not already posted:
    • (Note that Katello uses dots instead of dashes for release candidates, e.g. 4.1.1.rc1 not 4.1.1-rc1)
    • Make sure to run ./tools.rb setup-environment first
    • Run ./tools.rb procedure release katello 4.8.0.rc1 <%= target_date %> @cintri84 @zhunting in tool_belt
    • Post the output in Development with a “Releases” tag
  • Branch docs
    • Draft release notes in markdown (eample), 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, ecluding bug fies for issues introduced during the release cycle, include link to bug numbers. You can auto-generate changes using the changelog command in tool_belt (make sure to run the setup-environment command first)
      • Add contributor list on release notes page: git shortlog -s KATELLO-4.7..KATELLO-4.8
    • Create a pull request to theforeman/foreman-documentation:
      • Locate the Foreman documentation PR for the current version - eample here
      • Add Katello-related content in the same file and base the PR off of the Foreman PR
    • Clone GitHub - theforeman/apidocs: API documentation for Foreman and its plugins and follow the Katello README section to update the API documentation.
  • Prepare “Katello Next” and future redmine versions
    • Rename the “Katello Next” release to Katello 4.9.0
    • Recreate the “Katello Next” release and indicate that it is a placeholder for issues belonging to the net version of Katello
    • Create the next ‘z’ release: Katello 4.8.1

Release Engineer

  • Run ./tools koji configs/katello/4.8.yaml --confirm from tool_belt to create Koji tags
  • Run ./tools mash-scripts configs/katello/4.8.yaml from tool_belt to create Koji mash configs and open PR to tool_belt to commit
  • Copy mash configs to Koji scp mash_scripts/katello/4.8/*.mash root@koji.katello.org:/etc/mash/
  • Update the branch map in the mash script and deploy it to Koji scp collection-mash-split.py root@koji.katello.org:/usr/local/bin
1 Like