Skip to content
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

Change how and when we verify test material version skew #994

Open
smlambert opened this issue Apr 6, 2024 · 0 comments
Open

Change how and when we verify test material version skew #994

smlambert opened this issue Apr 6, 2024 · 0 comments
Labels

Comments

@smlambert
Copy link
Contributor

smlambert commented Apr 6, 2024

We have a check that verifies whether scmReference (what tag we are using to build with) matches the aqaReference (the tag we want to test with) resolve to the same SHAs.

Currently this check is done by pulling a static copy of the testenv.properties file from the aqa-tests branch prior to any call to aqa-tests/get.sh which pulls in test material.

This solution makes certain assumptions, including that there is not already a resolution around tag names that happens when get.sh is run. Several PRs have been merged in recent months around this topic:

a) in the aqa-tests code change, if the tags in testenv.properties file does not exist, we fall back to the latest version of the tag with the same prefix, automatically update the testenv.properties file (as a recorded artifact of what tag tests will use and proceed to run tests with it. This change was made in aqa-tests repo, in the get.sh and checkTags.sh file, to account for the fact that some vendors are not using our Jenkins pipeline code to run their builds.

b) in the ci-jenkins-pipeline code change, added logic to instead of matching the tags of the 'test code' and 'jdk being built' directly, it resolves them to the SHA and checks if the SHAs match before proceeding. This new code is fine, but likely not necessary (given a) above) and is running with the static value of the JDK_BRANCH info pulled at this point https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/build/openjdk_pipeline.groovy#L78

So essentially, b) defeats the purpose of a), but is also not an approach that will be helpful for all vendors using AQAvit. We need to see if there is a later stage to check for version skew, or better handle our dryrun case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Todo
Development

No branches or pull requests

1 participant