General Retrospective for January 2025 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.

[Haroon-Khel]

Release pipelines which have some errors in the downstream jobs are not able to generate the release summary report in TRSS.
As an example https://trss.adoptium.net/resultSummary?parentId=6780fa67f66194006d2f37b1 which corresponds to https://ci.adoptium.net/job/build-scripts/job/release-openjdk11-pipeline/51/

SL/Jan15: think this is related to the amount of failures to the point where it essentially exceeds the character limit in the release report. Pipelines with a some errors can be generated, pipelines with a massive amount of information to 'share' exceed the limit. aqa-test-tools/issues/xxxx to print out a msg if limit is hit (so the user knows no report will be generated).

[Haroon-Khel]

https://adoptium.slack.com/archives/CLCFNV2JG/p1736788317222669?thread_ts=1736429650.249329&cid=CLCFNV2JG

Regarding the release trigger getting confused with the tags, the picture below is an example of how it might get confused

The top 3 entries are fine; we have a tag jdk-23.0.2+22 which we want to use as a dryrun so we push a dryrun-ga tag, jdk-23.0.2-dryrun-ga, which has the same commit sha as jdk-23.0.2+22, and jdk-23.0.2+22 has a corresponding jdk-23.0.2+22_adopt tag present. All is good. Except jdk-23.0.1-dryrun-ga is present which shares the same commit sha as jdk-23.0.2+22. This will confuse the trigger and/or the downstream release pipeline it kicks off. The solution is to remove the jdk-23.0.1-dryrun-ga tag (delete it)