-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
Introduce a new "prototype" pipeline for new potential platforms to initially run in #473
Comments
@andrew-m-leonard Is this up for trials by interns? I would love to tryout! |
hi @cornelia247 , this item is quite extensive, but we will not be implementing it until after the October release, so into November. Also, this requires certain Admin access for some of the updates/testing. |
I think Loongson could be a good candidate for this issue. |
weekly build for jdk8/11 has bisheng corretto and dragonwell, this prevents archive temurin. |
^ this is also on jdk17 https://ci.adoptopenjdk.net/job/build-scripts/job/weekly-openjdk17-pipeline/: bisheng and openj9 |
maybe risc-v should also be in the prototype, rather than manually created by coping from old jobs |
Mark: when code is done, we need to update docs of "how to generate these prototype pipelines" |
one more question: do we want to run the targets of prototype in the " weekly"? @andrew-m-leonard |
@zdtsw Yes agree, weekly just runs the nightly targets |
Just to be clear, are we suggesting in the last two comments that the prototype builds would NOT be included in the weekly runs? That would seem undesirable as it would not allow us to regularly run and see the output of the full set of test suites on the prototype platforms. |
We will not have prototype running in the "normal" weekly pipeline, the result from prototype weekly no need archive, to save some disk space, |
@zdtsw @andrew-m-leonard Any ETA on getting this running regularly? @luhenry is keen to get the RISC-V pipelines live again now that the testing has been included as per #545 |
after some comments, we have decided to rename "prototype" into "evaluation" for the new type of pipelines |
The implementation is done, changes are under review, hopefully we can get this issue closed by this week |
@luhenry looks like riscv for jdk20 is working now, https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk20/job/jdk20-evaluation-linux-riscv64-temurin/ |
The latest release (and a few previous ones too) contains |
so, the risc-v binaries you saw from each nightly builds (we do not call them as release, only nightly build, or pre-release) were from the old nightly pipelines (before evaluation pipelines were setup) The first run of evaluation pipeline was done on 3rd Jan. and we do not "publish" binaries from evaluation pipeline to GitHub binary repo, any nightly builds after 3rd Jan should not include risc-v. |
@zdtsw IMHO we should be publishing them in teh GitHub repositories so that users can get to previous binaries to do comparisons between them if things start failing. Pulling them out of CI isn't ideal. This would make it easier for people to get a new platform out of evaluation state and be able to retest with earlier builds if required when looking at problems. It wasn't quite clear to me from your earlier comment whether you plannned to set up a prototype-weekly pipeline that would publish. |
standard weekly pipeline will archive the last 2's binaries in Jenknis disk, but not publish to GitHub binary repo. If we want to publish evaluation from night builds, we need to set it to "Nightly" instead. |
An open discussion for evaluation pipeline: the implementation made for evaluation pipeline has certain difference than the "nightly" we have, and this need more input from everyone:
|
My view is that ideally I'd like there two be one github release for each nightly run, however I appreciate that would require some magic to synchronise up the releases, and we should see if that's feasible somehow. Without that, each alternate one would have "normal" and "experimental" nightlies which could be somewhat confusing for the end users unless it was made clear in the name somehow. Looking forward to hearing any other views on the subject :-) |
My vote would be maybe to ensure it differs, although that maybe tricky as the target release doesn't exist until the pipeline finishes. |
Nightly pipelines at the moment have no association to a single github published release, so if 2 nightly pipelines run one night they will be published to two different releases. |
What's the bar to take a pipeline from "experimental" to "normal"? For |
My expectation was that the differentiation between "evaluation"/"experimental" pipeline versus "normal"/"release" pipeline was to have only the set of platforms we officially release (slide 27 of the 2023 Program plan / those platforms that we TCK and publish). Noting that I would also expect that we would still publish nightly/beta builds of platforms found in evaluation pipeline (and had not remembered the ole' timestamp dilemna), but as @andrew-m-leonard noted in #473 (comment) there is no obligation for a single nightly/beta release (no matching timestamp requirement). |
This may be controversial but I disagree ...TL;DR The end-users of this shouldn't really have to care about what we do internally when they are looking to locate a build on a platform they are interested in.:
Marking the nightly releases as easily identifiable as being the experimental ones mitigates point 1 a little but I'd still suggest it isn't an ideal solution. |
as for the downstream job name, it was added in
for evaluation and release job. @smlambert if this creates difficulties for TRSS, we can change the logic. |
re: #473 (comment) - I was just raising the question on whether it was needed to rename child jobs, agree that top-level job name should take the extra word as a distinction, just posing question on whether it was needed or desirable to rename children (to consider pros/cons/value). related: adoptium/aqa-test-tools#765 - and associated PR which will ignore evaluation and release words to allow us to incorporate build and smoke test results into the same grid as the AQA test results. |
I share the same concern about renaming some child jobs. The release and evaluation pipelines trigger some renamed child jobs by adding |
gathering a bunch of related open issues:
Will have this issue closed first (feel free to re-open) |
New platforms that are not candidates for release need time to bed in and prove their stability. We should introduce a new "prototype" (or suitably named) pipeline that is perhaps run once a week for such platforms.
The text was updated successfully, but these errors were encountered: