General Retrospective for September and October 2024 Releases

[adamfarley]

Summary

A retrospective for all efforts surrounding the titular releases.

All community members are welcome to contribute to the agenda via comments below.

This will be a virtual meeting after the release, with at least a week of notice in the #release Slack channel.

On the day of the meeting we'll review the agenda and add a list of actions at the end.

Invited: Everyone.

Time, Date, and URL

Time: Date: URL:

Details

Retrospective Owner Tasks (in order):

• [ ] Post retro URL in #Release around the start of the new release.
• [ ] Wait until most builds are released, with no signs of a respin.
• [ ] Announce the retrospective's date + time on #Release a week in advance.
• [ ] Host the retrospective:
  • Go through the agenda.
  • Create a list of actions.
• [ ] Process each action:
  • Create a "WIP" issue including the source comment.
  • Add the issue to the current iteration.
  • Add an issue link to the action list.
• [ ] Create a new retrospective issue for the next release.
• [ ] Set a calendar reminder so you remember to do step 1 before the next release.
• [ ] Close this issue.

TLDR

Add proposed agenda items as comments below.

[andrew-m-leonard]

build repo release branches don't have mandatory PR review, probably as settings regex does not match...?

[andrew-m-leonard]

build repo code freeze check for the release branch was not enabled, but then I thought, do we really need it, especially if we get the release branch mandatory review fixed?

[andrew-m-leonard]

Currently dryrun tags are the tag previous to the suspected actual GA tag, since it's not easy to "reset" the auto-trigger, maybe we ought to fix that...?

fyi, a bit naff!, but to do a trigger "reset" (since I had to do one for a failed dryrun trigger!) As a Jenkins "Admin":

• Go to "jenkins-worker" node "Script Console": https://ci.adoptium.net/computer/jenkins%2Dworker/script
• Remove the workspace "tracking" file that contains the last triggered SCM:

  println "rm /home/jenkins/workspace/build-scripts/utils/releaseTrigger_jdk23/workspace/tracking".execute().text

[andrew-m-leonard]

getTestDependency was failing on temurin-compliance due to no authentication: https://github.com/adoptium/aqa-tests/issues/5589 This was failing in the July release as well, but failure of this stage does not fail the job.. which means we use the workspace cache, if we have one, and whatever maybe there!

[smlambert]

re: https://github.com/adoptium/temurin/issues/54#issuecomment-2344011663

This was failing in the July release as well, but failure of this stage does not fail the job.. which means we use the workspace cache, if we have one

Do not think there is anything in the dependencies list that gets used by the TC jobs (but could affect if we are using TC Grinder to verify AQAvit tests, though most dependencies do not change often, so cached versions are fine).

[andrew-m-leonard]

TRSS needs new JDK versions adding before release week, release-openjdk23-pipeline was missing.

SL/Sept12 - now added

[andrew-m-leonard]

We should be more accurate with our release process terminology: Publish updates to the containers to dockerhub should be: Publish docker images to dockerhub

[sophia-guo]

When doing the triage, the tap files of the grinder should be attached to the triage issue , for example https://github.com/adoptium/aqa-tests/issues/5598. So the job https://ci.adoptium.net/view/Test_grinder/job/TAP_Collection can collect tap files of pipeline job and tap files of grinder.

[sophia-guo]

For trss if rerun job passes the corresponding test job status should be set as pass, so no need to do the extra triage. For example https://trss.adoptium.net/resultSummary?parentId=66e2f744d24e1b006e88e097 aarch64_mac, extended.openjdk rerun passed, the extended.openjdk should set as success.

[sophia-guo]

AQA triage, using the auto generated rerun links of rerun test job, which has already prepopulated either failed test targets or failed test cases. https://ci.adoptium.net/job/Test_openjdk23_hs_extended.openjdk_x86-64_windows_rerun/19/

[smlambert]

For trss if rerun job passes the corresponding test job status should be set as pass, so no need to do the extra triage. For example https://trss.adoptium.net/resultSummary?parentId=66e2f744d24e1b006e88e097 aarch64_mac, extended.openjdk rerun passed, the extended.openjdk should set as success.

Quick checks to make when triaging, look at the rerun.tap file on the Jenkins job, if its green, nothing to do.

We should also have a different chiclet icon for this "state" where rerun job passes. Suggest a yellow chiclet with a small green circle in top right corner for that state and so forth. Related issue: https://github.com/adoptium/aqa-test-tools/issues/912