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

Conflicting third-party dependency locations preventing download #5427

Closed
adamfarley opened this issue Jul 9, 2024 · 1 comment · Fixed by adoptium/TKG#581
Closed

Conflicting third-party dependency locations preventing download #5427

adamfarley opened this issue Jul 9, 2024 · 1 comment · Fixed by adoptium/TKG#581
Assignees

Comments

@adamfarley
Copy link
Contributor

Summary
When downloading third party dependant jars, we get the jars and their shas from two different places, causing conflict

Details
In aqa-tests file JenkinsfileBase, we set a custom URL that jars can be downloaded from.

	def customUrl = "https://${jenkinsDomain}/job/test.getDependency/lastSuccessfulBuild/artifact/"

In TKG file getDependencies.pl, we previously used that custom URL (if set) to tell us where to download the jars from.

	# if customUrl is provided, use customUrl and reset $url and $shaurl
		if ($customUrl ne "") {
			$url = "$customUrl/$fn";
			if (defined $shaurl && $shaurl ne '') {
				$shaurl = "$customUrl/$shafn";
			}
		}

adoptium/TKG@c7cf199

However, in a later commit, we removed the line that sets $url to $customUrl, but kept the sha url code.
adoptium/TKG@87c75ad

As a result, we now get a jar's sha from the jenkins job "test.getDependency", but we get the actual jar from "dependency_pipeline".

Looks to me like we should re-add the line that adds the custom URL to the $url variable in getDependencies.pl, with an extra tweak to ensure that the artifact folder location is added as well (since test.getDependencies stores e.g. jtreg.jar in /jtreg instead of the artifact root).

Example

16:32:31  downloading https://ci.adoptium.net/job/dependency_pipeline/lastSuccessfulBuild/artifact/jtreg/jtreg5.1-b01.tar.gz
16:32:33  --> file downloaded to /home/jenkins/workspace/Test_openjdk22_hs_extended.perf_riscv64_linux_testList_1/../../testDependency/lib/jtreg_5_1_b01.tar.gz
16:32:33  downloading https://ci.adoptium.net//job/test.getDependency/lastSuccessfulBuild/artifact//jtreg_5_1_b01.tar.gz.sha256sum.txt
16:32:33  ERROR: sha checksum error.
16:32:33  --> file downloaded to /home/jenkins/workspace/Test_openjdk22_hs_extended.perf_riscv64_linux_testList_1/../../testDependency/lib/jtreg_5_1_b01.tar.gz.sha256sum.txt
16:32:33  Expected sha is: fbaf7a59b57bd3df33b6702eae52c8e0df3e315a0173115a5329ee58a9e70be2,
16:32:33  Actual sha is  : c0ad6c8868401176b764ea1d33b9cd1a67b0ea817ef1bc4f6122c74411e35895.
16:32:33  Please delete /home/jenkins/workspace/Test_openjdk22_hs_extended.perf_riscv64_linux_testList_1/../../testDependency/lib/jtreg_5_1_b01.tar.gz and rerun the program!

https://ci.adoptium.net/job/Test_openjdk22_hs_extended.perf_riscv64_linux_testList_1/6/consoleFull

@adamfarley
Copy link
Contributor Author

Here's the sort of fix I propose. Thoughts?

adoptium/TKG#581

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

Successfully merging a pull request may close this issue.

1 participant