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

Create Trestle pipelines #895

Open
smlambert opened this issue Jan 24, 2024 · 7 comments · May be fixed by #958
Open

Create Trestle pipelines #895

smlambert opened this issue Jan 24, 2024 · 7 comments · May be fixed by #958

Comments

@smlambert
Copy link
Contributor

We are trialing a way for JVM developers from WG member companies to do some feature testing on Adoptium infrastructure. We want to segregate these pipelines from the release and evaluation pipelines so that they are easy to differentiate and track.

They will have a prefix on the name (much like we do with release- and evaluation- pipelines) and trigger AQAvit testing with a suffix _trsl (suffixes already supported for AQAvit pipelines, _fips, _criu, etc). In this way, they will also be differentiated and more easily searchable in TRSS.

@smlambert
Copy link
Contributor Author

Will iteratively add documentation here.

@smlambert
Copy link
Contributor Author

Notes:

@sxa
Copy link
Member

sxa commented Nov 6, 2024

I notice that this is running the same platform specific build pipelines underneath the top level ones so it is using the _temurin suffixed ones. Has any consideration been made to using the _hotspot ones instead for trestle? Clearly there are various implications of this (retention disk space being one) but it may be useful to have that separation, particularly since the trestle pipelines have to put in additional build options that would not be required for a "VARIANT=hotspot" build.
I ran a jdk8u pipeline earlier and that fell over due to the Temurin variant builds bedding our extra company name option which doesn't exist on a normal openjdk fork.

@smlambert
Copy link
Contributor Author

smlambert commented Nov 7, 2024

Yes, I would prefer to use the _hotspot variant but hit build failure upon running it, so shifted back to _temurin variant in order to build successfully.

@sxa
Copy link
Member

sxa commented Nov 7, 2024

Hmmm yeah I just did a quick test with one of the hotspot pipelines equivalent to a _temurin one I ran yesterday) and it fell over with - LMK if this looks similar to what you hit:

Loading library openjdk-jenkins-helper@null
Examining [adoptium/jenkins-helper](https://github.com/adoptium/jenkins-helper)
Attempting to resolve null as a branch
Attempting to resolve null as a tag
ERROR: Could not resolve null
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: No version null found for library openjdk-jenkins-helper
/home/jenkins/.jenkins/jobs/build-scripts/jobs/jobs/jobs/jdk8u/workspace/jdk8u-aix-ppc64-hotspot@tmp/jfrog/1202/.jfrog deleted
Finished: FAILURE

@smlambert
Copy link
Contributor Author

ERROR: Could not resolve null seems familiar, yes

@sxa
Copy link
Member

sxa commented Nov 11, 2024

Yes, I would prefer to use the _hotspot variant but hit build failure upon running it, so shifted back to _temurin variant in order to build successfully.

Interesting - would definitely be good to fix that. My initial though is that it might be problematic if the jobs haven't been regenerated in ages so are out of sync...

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

Successfully merging a pull request may close this issue.

2 participants