-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Add docker baking #1137
Add docker baking #1137
Conversation
Timings for image build: Previous master build: 5m 48s Checking master build to see if it's failing too |
"centos7_jdk8", | ||
"centos8_jdk8", | ||
"debian_jdk8", | ||
"debian_jdk11", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason to provide java11 for debian only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is just a reverse engineered version of what we're currently publishing, we can change it later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've intentionally limited the images we provide because each image we provide needs a maintainer that will care for the image after its initial definition and delivery.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarkEWaite I think this question was more, why only debian has jdk11 and not the other variants, especially because all the dockerfile's exist in the repo.
and I believe the answer is because historically each image was built and published serially adding each variant made the build take longer.
With the introduction of docker buildx bake
this moves it to a parallel build and isn't such a concern meaning we could introduce more variants if we wished, although I'd like to do it by retiring the jdk8 versions instead.
(build time is approx 5x faster now)
That work is really amazing as it brings a lot of clarity. Thanks for starting this |
docker-bake.hcl
Outdated
} | ||
|
||
variable "OWNER" { | ||
default = "jenkins" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to publish to jenkins4eval by default and override to publish to jenkins when running on trusted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why’s that? Publish is only run on trusted from what I can tell
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's commented out right now, but we do want to publish experimental.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what would get published there? I think the work I'm doing here replaces all that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The multi-arch images are not tested very well. The idea was we release them to jenkins4eval until they are tested more and then also publish them to jenkins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jenkins4eval is a dockerhub org that we use to publish and test docker image, it's an untrusted organization as everybody can push images to it from ci.j.io
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think experimental images belong in their own bake file.
and aren't really related to this PR?
In future someone can restore jenkins4eval is needed but it's not used atm?
Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
Thanks so much for this @timja! I installed Docker on a Ubuntu 20.04 aarch64 computer and ran
I was able to confirm that three of the four images can report their Java version and can report the contents of /etc/os-release. A sample of that output looks like this:
The
Is there anything I can investigate that would clarify why the centos image is different than the others? |
I'm not sure, It works just fine on my
I've been using the centos image to do all my testing |
@slide is there a reason we don't publish version specific versions of the windows images? https://hub.docker.com/r/jenkins/jenkins/tags?page=1&ordering=last_updated&name=windows |
Other than it's just not setup right now, no. We would need to change the |
The arm64 / aarch64 processor that I'm running is hosted on Oracle Cloud and is running Docker 1.10.7. I've seen the same failure on Oracle Linux 8 and on Ubuntu 20. Both failure cases were running on Oracle Cloud. I'll continue exploring as time allows. |
Is there anything blocking this PR? None of the multi-arch work here is enabled, it's plumbing for later. I've got changes to the publishing scripts locally that are pretty close to ready, but I don't want to load too much in each PR. |
Nothing blocking the pull request from me. I assume that the issues I'm encountering are either unique to my environment or are not yet actually relevant to use of this pull request. I'm able to use this pull request on my amd64 Debian 10 computer ("buster"). The Docker version 20.10.7 has the I'm not able to use this pull request for CentOS on the Arm64 Oracle Cloud instances where I'm running. I've confirmed the issue exists for Ubuntu 20 on Arm in that environment and for Oracle Linux 8 in that environment. I'm not able to use this pull request on the Arm64 Amazon Linux instance I have running on AWS because the Docker version provided with Amazon Linux does not seem to include the I'm not able to use this pull request on my amd64 Debian testing (pre-release of Debian bullseye). The Docker version installed on Debian testing is 20.10.5 and does not have the I assume for now that we'll only be running |
It should be supported from docker 19.03 @MarkEWaite. On older docker versions you may need to add:
I would recommend not worrying about it too much, we should be pulling docker from docker upstream repositories not package manager repositories so we should always be on the latest or close to latest anyway depending on when the base VM image was last built. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job! This PR is improving the build time and the rest is "pre-plumbing" so let's go. Thanks a lot for this!
I have just tried this on Fedora 33 with Docker version 19.03.13, build 4484c46 and got:
The old way worked fine there... |
@saper that is a good feedback: we should state clearly that Docker 20.10 is recommended,
|
My mistake - I thought I had buildx working already on this box but it wasn't - had to follow https://github.com/docker/buildx/#with-buildx-or-docker-1903 to get it installed and the |
ref #1133 (comment)
This is part 1 in a series of PRs
It converts the build process (CI only) to docker buildx bake which parallelises the build, and will allow moving shell script logic / makefile to declarative configuration
Already it shows that a number of the dockerfiles we have checked into the repo aren't being published which is not clear from looking at the scripts.
Remaining work for future PRs:
make
targets have been added in this PR to show how that will works390x
,ppc64le
static agents--set '*.platform=linux/amd64'
Above steps do not need to all be done in order, probably won't enable CI until publishing is ready although can have a PR up earlier.
Any thoughts / feedback?
Help would be loved as well cc @dduportal / @olblak