Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Update parsing TEMURIN_BUILD_ARGS #3824
Update parsing TEMURIN_BUILD_ARGS #3824
Changes from 7 commits
5ebfb93
d98d20e
55ce82b
1415629
8af8e39
75e969a
b2050b5
6919b17
5ebad2c
636999a
0ee465d
2ccf570
c614969
baafa00
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should assume no DevKit default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be a bit happier if we changed the name of this. The devkit on Linux still using gcc so this may cause some confusion. Maybe
setNonDevkitGccEnvironment
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes agree, that is what was going through my head when I suggested it, ie.set the Gcc environment when not using a DevKit...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
split this method into separate:
setGccEnvironment()
setAntEnvironment()
Also remove check on javac, as it might not be located in /usr/lib/jvm/jdk-
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally go with this as it feels less complex than using an array - you can add extra things to filter out later with multiple
-e
parameters if needed. But I'm ok with either approach. We could also combine this with the jdk-boot-dirsed
below.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a code standard issue. I personally feel the array is simpler if extra options need to be filtered out. Using multiple -e make it less readable and more error-prone for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced this logic is working. When I tried it out it converted:
in the string to:
so if you want to leave it with the bash-specific construct, I think you'll need to switch
//
to/
in the translation expression.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confused. @sxa which logic did you try? Seems you were trying
buildArgs="$(echo buildArgs | sed -e 's/--enable-sbom-strace//g')"
? As I said I would prefer using the array, similar to the window reproducible comparing script.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the version with sed works ok - the current version with the array adds in an extra
/
unless you remove one of them as you can see in this example:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noting that this may be a little confusing to anyone reading this to see a local variable
using_DEVKIT
and a global oneUSING_DEVKIT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should remove these bits of sed that quote the configure args completely at the moment.
While the format of the SBOM changed to ensure the configure args quoted in the SBOM this is still needed if we want to rebuild the last GA with these scripts (which require the devkit adjustments too, so we can't just rely on using an old version of the temurin-build repo to rebuild the latest GA)
Ref: Old GA SBOM without quotes - New SBOM with quotes
Can we (at least until we've done a few more GA levels) do something to detect if the
makejdk_any_platform_args
is already quoted, and if not apply thissed
command?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My question would be it's currently used by anyone outside of Adoptium for former GAs? It's more like under development instead of production, which should allow the failures? For now if the PR is not in the issue with the devkit still exists. That is the issue with using the an old version of the temurin-build repo to rebuild without devkit adjustments will be an known issue. If necessary I would prefer to update some related documents to address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are actively pushing the story that we're reproducible it would be a mistake not to be able to do this with the scripts easily. I've done videos in the past and if we now have to say "Well we can't do that just now" it's not a good story for the community. I strongly believe we should support that scenario and that these scripts should never be considered only for our internal use.
It should be fairly simple to support this. Going forward we will be in the situation where we can point people at the GA SHA of temurin-build (although this should be a fallback - I would rather have the HEAD version able to support as a minimum one year of GA builds so that users wanting to verify our builds don't have to figure out how to get the correct version) but in the meantime I feel it's very important to allow end users to be able to prove reproducibility easily given how much we're pushing this in our marketing at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any such document would be very time limited (since we'll have this sorted in a release or two) and I'm not sure how we'd publish that in a way that our end users interested in verifying our reproducibility would be likely to find it. The reproducible build script has already been publicised in the past (I wrote it specifically with the goal of having others able to run it to verify what we're saying about reproducibility) so I feel it's important that it can be seen to work as demonstrated previously with the most recent GA level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following after the
jq
line that setsTEMURIN_BUILD_ARGS
should be ok for all situations:Noting that the removal of
--with-jobs=
is because it's not necessary for reproducing the builds, and was added to work around an issue whenenable-sbom-strace
is enabled (Ref: adoptium/ci-jenkins-pipelines@68ffc9e). This could potentially be done in the same place as the removal ofenable-sbom-strace
but it needs to be done before the other translations in the above sed are done.I've verified the above changes with the following and it looks good:
./linux_repro_build_compare.sh https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk21u/job/jdk21u-linux-aarch64-temurin/195/artifact/workspace/target/OpenJDK21U-sbom_aarch64_linux_hotspot_2024-06-13-10-35.json https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk21u/job/jdk21u-linux-aarch64-temurin/195/artifact/workspace/target/OpenJDK21U-jdk_aarch64_linux_hotspot_2024-06-13-10-35.tar.gz
(Now deleted so can't be re-built again)./linux_repro_build_compare.sh https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.4%2B5-ea-beta/OpenJDK21U-sbom_aarch64_linux_hotspot_21.0.4_5-ea.json https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.4%2B5-ea-beta/OpenJDK21U-jdk_aarch64_linux_hotspot_21.0.4_5-ea.tar.gz
./linux_repro_build_compare.sh https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.3%2B9/OpenJDK21U-sbom_aarch64_linux_hotspot_21.0.3_9.json https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.3%2B9/OpenJDK21U-jdk_aarch64_linux_hotspot_21.0.3_9.tar.gz
Note to self: The location specified by
--user-openjdk-build-root-directory
should be cleared before each subsequent attempt.Second note to self: This script does not work if a fork of the adoptium/temurin-build is used as that repository is hard coded in the script, so - for example - jdk21u-linux-aarch64-temurin/197 does not work without a change to the script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assume those covers all possible combinations of configure-args of former GAs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated. @sxa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra blank line here should be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel it's nice to make this explicit for anyone that wants to replicate this outside the build jobs:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto, not sure this all of this right, we should use original configure-args, and update args that need to point to local path equivalents, eg.--with-ucrt-dll-dir needs to point at local Windows dir path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea maybe confirm with @steelhead31