-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General Retrospective for January 2024 Releases #13
Comments
Actions from previous retrospectives:
|
Topics rolled-over from last retrospective: 1. "Permission to publish" requests can be forgotten.One solution: Some form of Slack bot that recognises requests to publish, and notifies the poster once the required +1's have been accumulated. This bot could also supply a link that populates all of the relevant parameters correctly, e.g. "Grinder/parambuild/?SDK_RESOURCE=upstream&etcetc". Said bot could also remind the poster if the expected binary isn't present in the correct repository within an acceptable time period. Notes:
Discussion so far:
2. The task to update support dates is marked as completed, but we have received [an issue](https://github.com/adoptium/adoptium.net/issues/2443) to update them as they were not done.If it helps, I think this change was made on November 2nd at 2:02 PM GMT. One solution could be to automate this (e.g. If NextRelease != "EOSL" then NextRelease=x+10), so when every primary platform has been published, a PR is generated and Slack is notified for approval. |
Corrected the release pipeline generator link in RELEASING.md in the build repo from https://ci.adoptium.net/job/build-scripts/job/utils/job/release-build-pipeline-generator/ to https://ci.adoptium.net/job/build-scripts/job/utils/job/release-pipeline-generator/ |
Update release checklist template to remove arm32 from jdk21 table |
The release checklist may be out of date in regards to which builds to disable during release week. Currently the checklist suggests disabling standard and evaluation builds, where as historically we disable nightly testing only. Discuss what is most suitable |
Recommend that we recreate this PR openjdk/jdk#14942 to deal with issues with jtreg tests seen in AQAvit testing (see adoptium/aqa-tests#4960 (comment)). |
Recommendation to improve Deep History view adoptium/aqa-test-tools#837 |
Increased number of disconnects seen with Orka machines (see adoptium/aqa-tests#4960 (comment) which references adoptium/infrastructure#2536 and Slack thread for details). |
adoptium/infrastructure#2885 (comment) - No longer have Windows machines where certain jdk_tools tests can pass, hit a Wix toolset configuration error on all of our current set of Windows machines. |
adoptium/aqa-tests#4821 (comment) - [SXA: Ref: https://github.com/adoptium/infrastructure/issues/3043] |
Double check if tap files of the rerun test builds are collected or archived to upstream pipeline jobs. |
https://adoptium.slack.com/archives/CLCFNV2JG/p1705426218260209 Release trigger scripts will add an extra _adopt suffix to tags even if there already is one
This is caused by an _adopt tag being at the top of https://github.com/adoptium/jdk8u/tags (at this moment jdk8u402-b05-dryrun-ga_adopt is at the top). |
Update status template to remove 32bit platforms for jdk21 #18 |
TRSS seems to have slowed or stalled receiving and reporting test results, not sure why, whether its the Jenkins server at capacity when queried, or something on the TRSS server. Needs investigation. adoptium/infrastructure#3354 |
The release publish job seems to take the release name as input. Accidents can happen if the release name doesn't match the common pattern. E.g. |
release tool unexpected operator error in console, though job shows successful and uploaded artifacts successfully
[EDIT: SXA 22/Jan: Raised at https://github.com/adoptium/github-release-scripts/issues/145 after I spotted it today] |
Tests running on aarch64 Linux nodes are painfully slow and hitting 10hr time limit, so aborting and need relaunching adoptium/aqa-tests#4983 (comment) (not seen during dry run) Down to a single node online for AQAvit triage Similar issues for arm_linux machines and x64 alpine-linux machines mid-way through the release activities |
4 jdk21 windows testcases can not pass on ci.adoptium.net Jenkins machines, but can on temurin-compliance Jenkins machine (adoptium/aqa-tests#4983 (comment)) |
1 minute timeout waiting for an Orka node is not long enough:
|
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as resolved.
This comment was marked as resolved.
https://ci.adoptium.net/job/openjdk_build_docker_multiarch/ running on test-sxa-armv7l-ubuntu2004-odroid-2 and making it unavailable, which is the only online machine arm_linux machine where certain openjdk tests are known to pass (the other static docker nodes are not configured to allow for a green run of sanity.openjdk and extended.openjdk test targets). There should be 'less pressure' on the -odroid machines once the issues running in the infra static docker nodes are addressed, alternatively, just as we disable testing during release, should we be disabling or reducing the frequency of this docker_multiarch job during release. |
release tool: jdk8 x32 windows, I missed the .msi files in this job When I went to correct the mistake by uploading the 2 missing msi files in this job (and others varyiing the regex), hit this error:
Also noting that the verifying Checks when uploading are helpful (indicated 21/23 files were uploaded), but would also be helpful to see this in a Dry run, as it would then help avert more problems. Will be good to move to our more user-friendly wrapper job (that is now ready to deploy) practicing using it before next release period. |
https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/8089/ was published with a name missing the
|
https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/8104/console reports an error when publishing jdk11 release notes release script verification appears to run a check against Mac aarch64 during this run
Not seen when publishing release notes for JDK8, JDK17 and JDK21 |
aarch64_mac release jdk-11.0.22+7.1 and jdk-11jdk-11.0.22+7. Uploading OpenJDK11U-jdk-release-notes_11.0.22_7.json is using tag jdk-11.0.22+7, and releaseCheck.sh is checking doubled aarch64_mac files. If it's uploading release notes only might just skip check process. |
@smlambert @sophia-guo My gut feel from the output is that this is likely another symptom of my comment above where it's finding artifacts that are in a tag which is superset of others - in this case I would guess that it's picking up and counting all artefacts in releases that are in jdk-11.0.22+7.1 as well as jdk-11.0.22+7 so finding twice as many. e.g. in my comment a parameter to the check script of
I think it would be better to add the release notes into the check in the same way as we do for the source archive (Noting also that Shelley's log above shows |
Night tests are disabled during releases. However if Pr in ci-jenkins-pipeline is merged during the releases the tests will be re-enabled again as jobs are regenerated. |
Shelley action: Go through Post-release actions from AQAvit triage issues and create issues for them: JDK21:
JDK17:
JDK11:
JDK8:
|
Retrospective actions summary Adam:
Shelley:
|
Suggest that the banner gets taken down when the blog post is published, since that is an appropriate time to mark the end of the release. (noting our banner is still up, and we are completed the main aspects of the release at this time). |
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: 2pm GMT, 9am EST
Date: Monday, 29th of January
URL: https://eclipse.zoom.us/j/85862065826?pwd=yXE1cYzqn2MnHv0BSq36jaTlAxqGxq.1
Details
Retrospective Owner Tasks (in order):
The text was updated successfully, but these errors were encountered: