Correct by platform archive AQAvitTapFiles.tar.gz location

[andrew-m-leonard]

The "by platform" AQAvitTapFiles.tar.gz archiveArtifact location is wrong, so is not finding it:

13:36:43  + find target/linux/x64/temurin/AQAvitTaps -type f -name *.tap -exec tar -czf target/linux/x64/temurin/AQAvitTaps/AQAvitTapFiles.tar.gz {} +
[Pipeline] fileExists
[Pipeline] {
[Pipeline] archiveArtifacts
13:36:44  Archiving artifacts
13:36:47  ‘AQAvitTapFiles.tar.gz’ doesn’t match anything, but ‘target/linux/x64/temurin/AQAvitTaps/AQAvitTapFiles.tar.gz’ does. Perhaps that’s what you mean?
[Pipeline] }
13:36:47  ERROR: Error during copy and archive artifacts for build job: build-scripts/jobs/jdk23/jdk23-linux-x64-temurin
13:36:47  ERROR: No artifacts found that match the file pattern "AQAvitTapFiles.tar.gz". Configuration error?
13:36:47  Setting overall build result to FAILURE

When I fixed the the platform AQAvitTapFiles.tar.gz’ location, I forgot to change the achived artifact target!

[github-actions]

Thank you for creating a pull request!

Please check out the information below if you have not made a pull request here before (or if you need a reminder how things work).

Code Quality and Contributing Guidelines

If you have not done so already, please familiarise yourself with our Contributing Guidelines and Code Of Conduct, even if you have contributed before.

Tests

Github actions will run a set of jobs against your PR that will lint and unit test your changes. Keep an eye out for the results from these on the latest commit you submitted. For more information, please see our testing documentation.

In order to run the advanced pipeline tests (executing a set of mock pipelines), it requires an admin to post run tests on this PR.
If you are not an admin, please ask for one's attention in #infrastructure on Slack or ping one here.
To run full set of tests, use "run tests"; a subset of tests on specific jdk version, use "run tests quick 11,21"

[smlambert]

Do these changes imply that we now have many artifacts instead of a single one? (which then needs to be accounted for in later verification and upload steps? I think I missed seeing the initial change, that has the trickle down effect (requires changes in other areas). Guessing this is what @sophia-guo was referring to, regarding verification scripts, requiring updates to handle this new scenario.

[andrew-m-leonard]

Do these changes imply that we now have many artifacts instead of a single one? (which then needs to be accounted for in later verification and upload steps? I think I missed seeing the initial change, that has the trickle down effect (requires changes in other areas). Guessing this is what @sophia-guo was referring to, regarding verification scripts, requiring updates to handle this new scenario.

@smlambert @sophia-guo Ok, so I was wondering if this looked right!
What we have currently is:

1. an archive "by platform" in target/OS/ARCH/VARIANT/AQAvitTaps/AQAvitTapFiles.tar.gz
2. and an overall "single all pipeline" in AQAvitTaps/AQAvitTapFiles.tar.gz

Is that correct or should we just have (2) ?
PR e694798 implies both "Tap files per platforms keep as before."?

[smlambert]

I like them organized by platform, but then the final requirements are that:

• all TAP files, including any Grinder TAP files that are gathered during triage are verified by these scripts
• 1 tar.gz containing all TAP files for a release gets uploaded to the binaries repo (related: Ensure we are pushing AQAvit TAP files to the binaries repository for each release github-release-scripts#96)
• we fix the marketplace API to point to the single tar file (related: Reorganize the tap result link aqavit_tapresult_link marketplace-api.adoptium.net#33)

[andrew-m-leonard]

I like them organized by platform, but then the final requirements are that:

* all TAP files, including any Grinder TAP files that are gathered during triage are verified by these [scripts](https://github.com/adoptium/aqa-tests/tree/master/buildenv/jenkins/tapVerification)

* 1 tar.gz containing all TAP files for a release gets uploaded to the binaries repo (related:  [Ensure we are pushing AQAvit TAP files to the binaries repository for each release github-release-scripts#96](https://github.com/adoptium/github-release-scripts/issues/96))

* we fix the marketplace API to point to the single tar file (related: [Reorganize the tap result link aqavit_tapresult_link marketplace-api.adoptium.net#33](https://github.com/adoptium/marketplace-api.adoptium.net/issues/33))

• I think the "by platform" tar.gz does now include all the "re-run" sub-testjobs @sophia-guo ? but manually run Grinder's would need adding manually?
• I query whether the "single tar.gz" for the whole "openjdkNN-pipeline" job is really useful, it seems to be duplicating the "by platform" ones. The above also states 1-tar per release, and we may not always have 1 "openjdkNN-pipeline", especially if we decide to split "primaries" from "secondaries".

[andrew-m-leonard]

Test with this PR: https://ci.adoptium.net/job/build-scripts/job/openjdk21-pipeline/292/

[smlambert]

Andrew, to be clear, there is no expectation that we can produce the single tar file, verify it and upload it as a direct part of the release pipeline. It will have to be triggered later, due to the fact that on average we have 20+ Grinder TAP files to include (due to infra or other issues during a release).

[andrew-m-leonard]

Test with this PR: https://ci.adoptium.net/job/build-scripts/job/openjdk21-pipeline/292/

Looks good

[steelhead31]

Looks good.

[sophia-guo]

This is not correct. The reason is the revert changes #1040 is auto or forcefully merged into taps 6e22834 by hit some button of github issues ( not by the PR author). Feels like some new features of github, reviewers has the permission?

Something like this

Those per platform archive are unnecessary and duplicate. Should be deleted. Archives are done by https://github.com/andrew-m-leonard/ci-jenkins-pipelines/blob/8cc041a8c8e96c5c48a984f972bfd642b78f33d3/pipelines/build/common/build_base_file.groovy#L1014-L1040

See PR #1058