learning go on updatecli ^^
i think its better to fix the plugin manager cli than to maintain a seperate tool, but its your time :)
oh! renovate is Jenkins-specific... I thought it was just another generic GitHub tool
no, renovate is a generic tool - https://www.whitesourcesoftware.com/free-developer-tools/renovate/
In my opinion, far surperior to dependabot that only handles a couple package managers.
updatecli is the one jenkins-infra created
In my opinion, far surperior to dependabot that only handles a couple package managers.
updatecli is the one jenkins-infra created
Oh the link I was reading was for the Jenkins module for renovate
I need maintainer review
Reviewed and explored jenkinsci/docker#1326 from my Ubuntu 20.04 machine and found no issues. I think we should consider delaying the execution of that change until Monday morning so that we have more time to handle surprises if they happen
well, I'll give Jenkins points for persistence. this one job has been waiting for a "dind" agent for 26 days
I'll probably have to rebuild this job to build using kaniko or img because all the docker in kubernetes articles I've seen so far assume that kubernetes is using docker as its container engine. I'm not
or maybe podman/buildah
It probably shouldn't matter. If you expose the containerd socket you can still probably use docker.
yeah, I don't actually want to reduce my security thusly
this article looks interesting: https://aws.plainenglish.io/build-docker-containers-on-kubernetes-with-jenkins-and-kaniko-45dc35e89da7
despite the "don't use the controller image, use the master image". d00d, they're the same thing
@timja: @MarkEWaite The build that are fixing the jenkinsci/docker images takes more than 1 hour to be executed, which hits the 1 hour hard timeout. I don't see the "faulty" manifest being updated (example:
skopeo inspect --raw docker://docker.io/jenkins/jenkins:2.319.1-alpine ) in the DockerHub: I assume that manifest are only updated once buildx finished all its build.
To fix that, I'll replay the principal build on trusted.ci, on the weekly 2.318 which is out of the publish scope (last weekly before the N-1 LTS - 2.319.1-) and i'll test that it behaves as expected.
Once ok (e.g. once manifest fixed + publish script forced to this version to see it as "published"), then I'll replay version per version until all is fixed
Once ok (e.g. once manifest fixed + publish script forced to this version to see it as "published"), then I'll replay version per version until all is fixed
(sorry, tha might be messy, hence the step by step on older and almost never used versions)
ok, so it is interesting. When doing a "docker buildx bake --push", the manifest is pushed as
application/vnd.docker.distribution.manifest.v2+json if there is only 1 CPU arch. It only updates it when adding another CPU arch.
It means that my update in the PR jenkinsci/docker#1326 is not enough, because it assumed implicitly that all manifest are
application/vnd.docker.distribution.manifest.list.v2+json . I realize that now: I need to update the script.
For information :)
=> what is new is that the jenkinsci DockerHub organisation is now badged (for DockerHub users) as "Open Source Program", e.g. clearly more trustable than
dduportal for instance :p
well no, jenkinsci is listed as deprecated, please see jenkins
1 reply
jenkinsci updated the blueocean image 7 hours ago as well
but still, nice work getting that badge!
(which is where that image is generated, and has probalby not been updated jenkins wise since I was at CB)
https://twitter.com/_crev_/status/1524375218449485826?s=21&t=L0pO8WHkl4YuYiNFTRIz4g that could help a lot to help visualizing the jenkins/docker-*-agent links to each other’s \o/
As I intended to finally do, it seems they add a specific cst.yml for windows
currently setting up a "-windows" prefix for windows cst tests, with a fileExist test in the final script
hervelemeur: this is definitively acceptable to skip the "test" steps for the windows container for this first step. The lint, build, deploy is already a strong first step