LTS 2.361.1 - Sep 7, 2022

Release Lead

@krisstern

Prep work

• LTS baseline discussed and selected in the Jenkins developers mailing list
  See the discussion thread

• Create or update release branch in jenkinsci/jenkins, e.g. stable-2.277, use the init-lts-line script

• Create or update release branch in jenkins-infra/release, e.g. stable-2.277.

  • Modify the RELEASE_GIT_BRANCH and JENKINS_VERSION values in the environment file (profile.d/stable) to match the release.
  • Modify the PACKAGING_GIT_BRANCH value in the packaging script (Jenkinsfile.d/core/package) to match the release.
  • For more info, refer to stable.

• Create or update release branch in jenkinsci/packaging, e.g. stable-2.361

• Create pull request to update bom to the weekly version that will be the base of the release line (strike this out for new point release)
  Initiate new LTS baseline 2.361.x jenkinsci/bom#1387

• Create pull request to update configuration-as-code integration tests to the weekly version that will be the base of the release line (strike this out for new point release)
  Initiate new LTS baseline 2.361.x jenkinsci/configuration-as-code-plugin#2093

• Review Jira and GitHub pull requests for additional LTS candidates, adding the 'lts-candidate' label, and ensure that all tickets are resolved in jira
  https://issues.jenkins.io/issues/?filter=12146

• Backporting announcement email - generate-backporting-announcement script

• Update jira labels for lts-candidate issues, either add 2.361.1-fixed and remove lts-candidate or add 2.361.1-rejected, and retain lts-candidate
  https://issues.jenkins.io/issues/?filter=23740

• Backport changes, create a local branch in jenkinsci/jenkins, run the list-issue-commits script to locate commits via jira ID, some manual work is required to locate them if the issue ID wasn't present at merge time, backport with git cherry-pick -x $commit
  First backporting for LTS 2.361.1 jenkinsci/jenkins#6993
  Second backporting for LTS 2.361.1 jenkinsci/jenkins#7063

• Open backporting PR with into-lts label and summary of changes in description from lts-candidate-stats script and the selected Jira lts-candidates
  First backporting for LTS 2.361.1 jenkinsci/jenkins#6993 (comment)
  Second backporting for LTS 2.361.1 jenkinsci/jenkins#7063 (comment)

• Review ATH, bom and configuration-as-code integration tests results
  🔴 ATH: https://ci.jenkins.io/job/Core/job/acceptance-test-harness/view/change-requests/job/PR-898/
  🔴 BOM: https://ci.jenkins.io/job/Tools/job/bom/job/PR-1409/4/
  🟢 JCasC: https://github.com/jenkinsci/configuration-as-code-plugin/runs/7789150204

• Prepare LTS changelog based on the style guide using the changelog generator - (docs team)
  Included on Docs office hours agenda for 11 Aug 2022 (Europe) and 12 Aug 2022 (Asia)

• Prepare LTS upgrade guide based on previous upgrade guides (docs team)
  Included on Docs office hours agenda for 11 Aug 2022 (Europe) and 12 Aug 2022 (Asia)

RC creation

• Merge backporting PR in jenkinci/jenkins using a merge commit (do not squash)

• Retrieve the url for the RC from the commit status (Jenkins Incrementals Publisher / Incrementals) of the last build on the stable branch (requires a passing build). Visit the jenkins-war URL and copy the URL of the war file, which would be something like https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.303.2-rc31385.6eec6c02fc3d/jenkins-war-2.303.2-rc31385.6eec6c02fc3d.war. If incrementals are broken you can deploy a build from your own machine with mvn -e clean deploy -DskipTests=true.

• Publish a pre-release Github release, e.g. sample currently we don't have a changelog for RCs

• Send announcement email, example

• Check with security team that no security update is planned. If a security update is planned, revise the checklist after the public pre-announcement to the jenkinsci-advisories mailing list

• Remark: A PR has been opened and merged dealing with an issue as documented at https://issues.jenkins.io/browse/JENKINS-69250 is affecting both the Setup Wizard and custom Headers implementations. It can be accessed here.

LTS release

• Publish changelog (one day prior to the release in case of a security update)

• Assure that contents of master branch have been merged to the stable branch in the release repository, e.g. stable-2.361
  Merge master branch into stable-2.361.1 #282

• Assure that contents of master branch have been merged to the stable branch in the packaging repository, e.g. stable-2.361
  Merge master branch into stable-2.361.1 jenkinsci/packaging#332

• Announce the start of the LTS release process in the #jenkins-release and #jenkins-infra IRC channels

• Run job on release.ci.jenkins.io if no security release for Jenkins is planned.

• Check LTS changelog is visible on the downloads site

• Publish GitHub release pointing to LTS changelog, sample

• Confirm Datadog checks are passing

• Confirm the Debian installer acceptance test is passing.
  For good measures, check the console log to confirm that the correct release package was used (e.g. search for 2.361).

• Confirm the Red Hat installer acceptance test is passing.
  For good measures, check the console log to confirm that the correct release package was used (e.g. search for 2.361).

• Adjust state and Released As of Jira issues fixed in the release (see the changelog for issue links)

• Create pull request to update bom to the newly released version
  (strike this out for new point release)
  Bump 2.361 profile to .1 jenkinsci/bom#1438

• Create pull request to update configuration-as-code integration tests to the newly released version
  Bump LTS 2.361 to point one release jenkinsci/configuration-as-code-plugin#2116

• Run trusted.ci.jenkins.io Docker image creation job.

• Confirm that the images are available at Docker hub

• Create a helpdesk ticket to update ci.jenkins.io, trusted.ci, cert.ci and release.ci to the new LTS release, example