You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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#L78So essentially,
b)
defeats the purpose ofa)
, 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.The text was updated successfully, but these errors were encountered: