AdamBrousseau

Results 65 comments of AdamBrousseau

@tushev the IBM Semeru Runtimes API is hosted at https://ibm.com/semeru-runtimes/api/v3 We have not yet had an official launch so there is no public doc yet. It is a fork of...

I think the ask is if we can submit a change to add a condition to that `if` line. Either `!openj9` or `JENKINS_URL.contains('adopt')` like we did here https://github.com/ibmruntimes/ci-jenkins-pipelines/blob/3d3cc13c466878349f5d6702381c6def555d4250/pipelines/build/common/create_job_from_template.groovy#L71

I see in the Adopt OpenJ9 builds the sign_temurin_gpg job is run ex https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-ppc64le-openj9/1339/consoleFull ``` 14:42:36 RUNNING sign_temurin_gpg for linux/ppc64le ... [Pipeline] build (Building build-scripts » release » sign_temurin_gpg) 14:42:36...

Is there a manual update needed to job(s) or will they automatically regenerate with the updated names?

I hit the same problem (as titled) but presents with a different error. I don't make it to the Git step. ``` 00:05:59.625 Successfully built fc4d639a1687 00:05:59.625 Successfully tagged build-image:latest...

From Semeru/OpenJ9 perspective it is not solved. I don't believe it is specific to OpenJ9. The workaround is you must run docker compiles on a machine where the host's user...

That might work. It's been so long I can't recall if I tried that or any of the users above tried it. If I get a chance I'll try it...

I got curious. Looks like dockerArgs got overloaded when this was added (cc @gdams ) https://github.com/adoptium/ci-jenkins-pipelines/pull/350 So it is now used for the pull command as well as when starting...

Not sure why this wasn't handled in #145. This issue is still valid even though the code has changed. IMO this line should be configurable https://github.com/adoptium/ci-jenkins-pipelines/blob/c5a5ed7dd940b95951dc3379fb73605c5f31f013/pipelines/build/common/openjdk_build_pipeline.groovy#L404

Changing which node the generator uses doesn't solve the problem. It simply moves it to another node. Unless the executor gets released while it waits, then the issue is still...