-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
[ci][1/n] Rebuild Docker images if necessary #11329
Conversation
f45948c
to
7fbdda7
Compare
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.
thanks @driazati, added some comments
677df48
to
e21ffa8
Compare
just a note for reviewers: the code is 99% done but will take a couple more iterations through CI once it’s verified before it can be merged (ie right now it still has testing code specific to this PR) |
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.
Phew, this Jenkinsfile is getting fun 😸 Thanks for working through this @driazati, is it possible to document some of the flow here in terms of using ECR as an intermediary cache before Docker Hub? Not necessarily this PR but it'd be great to have as a reference
jenkins/Jenkinsfile.j2
Outdated
).trim() | ||
def tag = "${date_Ymd_HMS}-${upstream_revision.substring(0, 8)}" | ||
{% for image in images %} | ||
update_docker({{ image.name }}, "tlcpackstaging/test_{{ image.name }}:${tag}") |
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 this is literally for testing, but I'll leave a comment just in case 😸
update_docker({{ image.name }}, "tlcpackstaging/test_{{ image.name }}:${tag}") | |
update_docker({{ image.name }}, "tlcpackstaging/{{ image.name }}:${tag}") |
e26df5b
to
6feabe4
Compare
97688a8
to
5c4613d
Compare
@Mousius I've re-worked this PR a bit, I'm weary about landing it all at once since it can potentially have a big impact on CI times. In a follow up PR I'll enable the docker image rebuilds based on the Docker Hub hashes behind a flag in Jenkins so we can turn it off if we need to, but this one is ready to go now |
11ff3d4
to
a462745
Compare
@tvm-bot rerun |
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.
@driazati I left a few questions but I'm ok with follow up in the next in the PR series. I also manually triggered CI to re-run as the bot didn't seem to be doing it?
jenkins/Build.groovy.j2
Outdated
timeout(time: max_time, unit: 'MINUTES') { | ||
try { | ||
cmake_build(docker_type, path, make_flag) | ||
// always run cpp test when build |
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 this comment has been sneaking around with this function but actually no longer relates to this function?
).trim() | ||
def tag = "${date_Ymd_HMS}-${upstream_revision.substring(0, 8)}" | ||
{% for image in images %} | ||
update_docker({{ image.name }}, "tlcpackstaging/test_{{ image.name }}:${tag}") |
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 presume this is just to avoid conflicts with the over night build?
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.
right, in the follow up(s) we'll switch it over
9110565
to
aa75d80
Compare
the bot is broken but fixes are in flight, we're looking into better ways to test these kinds of things before deploying (e.g. the merge functionality also isn't working due to some auth errors I haven't been able to sort out yet) |
This rebuilds Docker images and uses them in later stages in the same build. If the build is running on `main`, then the images are uploaded to Docker Hub automatically once the run is complete. Images are always rebuilt, but Docker Hub functions as a cache. If there have been no changes to `docker/` since the last available hash on Docker Hub, then the build will just use the images from Hub.
Nice work @driazati, looking forward to seeing this fully functional 😸 |
This rebuilds Docker images and uses them in later stages in the same build. If the build is running on `main`, then the images are uploaded to Docker Hub automatically once the run is complete. Images are always rebuilt, but Docker Hub functions as a cache. If there have been no changes to `docker/` since the last available hash on Docker Hub, then the build will just use the images from Hub.
This activates the code from apache#11329 behind a couple Jenkins flags: * `USE_AUTOUPDATED_DOCKER_IMAGES` - whether or not to use the dynamically determined docker images in the build * `PUSH_DOCKER_IMAGES` - whether or not to push built images to `tlcpack` on `main` These are there so we can quickly toggle this behavior off it breaks anything. Once this is on though, any docker changes in a PR should be reflected entirely in that build, so there would be no need for a separate PR to update the Docker images. We will have to see if this works in practice, as the docker image builds do download quite a bit of data (which can flake) and add some runtime overhead (about 30m), so when an update lands all PRs will end up needing to rebuild until the merged commit finishes.
This activates the code from apache#11329 behind a couple Jenkins flags: * `USE_AUTOUPDATED_DOCKER_IMAGES` - whether or not to use the dynamically determined docker images in the build * `PUSH_DOCKER_IMAGES` - whether or not to push built images to `tlcpack` on `main` These are there so we can quickly toggle this behavior off it breaks anything. Once this is on though, any docker changes in a PR should be reflected entirely in that build, so there would be no need for a separate PR to update the Docker images. We will have to see if this works in practice, as the docker image builds do download quite a bit of data (which can flake) and add some runtime overhead (about 30m), so when an update lands all PRs will end up needing to rebuild until the merged commit finishes.
This activates the code from apache#11329 behind a couple Jenkins flags: * `USE_AUTOUPDATED_DOCKER_IMAGES` - whether or not to use the dynamically determined docker images in the build * `PUSH_DOCKER_IMAGES` - whether or not to push built images to `tlcpack` on `main` These are there so we can quickly toggle this behavior off it breaks anything. Once this is on though, any docker changes in a PR should be reflected entirely in that build, so there would be no need for a separate PR to update the Docker images. We will have to see if this works in practice, as the docker image builds do download quite a bit of data (which can flake) and add some runtime overhead (about 30m), so when an update lands all PRs will end up needing to rebuild until the merged commit finishes.
This activates the code from apache#11329 behind a couple Jenkins flags: * `USE_AUTOUPDATED_DOCKER_IMAGES` - whether or not to use the dynamically determined docker images in the build * `PUSH_DOCKER_IMAGES` - whether or not to push built images to `tlcpack` on `main` These are there so we can quickly toggle this behavior off it breaks anything. Once this is on though, any docker changes in a PR should be reflected entirely in that build, so there would be no need for a separate PR to update the Docker images. We will have to see if this works in practice, as the docker image builds do download quite a bit of data (which can flake) and add some runtime overhead (about 30m), so when an update lands all PRs will end up needing to rebuild until the merged commit finishes.
This activates the code from apache#11329 behind a couple Jenkins flags: * `USE_AUTOUPDATED_DOCKER_IMAGES` - whether or not to use the dynamically determined docker images in the build * `PUSH_DOCKER_IMAGES` - whether or not to push built images to `tlcpack` on `main` These are there so we can quickly toggle this behavior off it breaks anything. Once this is on though, any docker changes in a PR should be reflected entirely in that build, so there would be no need for a separate PR to update the Docker images. We will have to see if this works in practice, as the docker image builds do download quite a bit of data (which can flake) and add some runtime overhead (about 30m), so when an update lands all PRs will end up needing to rebuild until the merged commit finishes.
This activates the code from apache#11329 behind a couple Jenkins flags: * `USE_AUTOUPDATED_DOCKER_IMAGES` - whether or not to use the dynamically determined docker images in the build * `PUSH_DOCKER_IMAGES` - whether or not to push built images to `tlcpack` on `main` These are there so we can quickly toggle this behavior off it breaks anything. Once this is on though, any docker changes in a PR should be reflected entirely in that build, so there would be no need for a separate PR to update the Docker images. We will have to see if this works in practice, as the docker image builds do download quite a bit of data (which can flake) and add some runtime overhead (about 30m), so when an update lands all PRs will end up needing to rebuild until the merged commit finishes.
This rebuilds Docker images and uses them in later stages in the same build. If the build is running on `main`, then the images are uploaded to Docker Hub automatically once the run is complete. Images are always rebuilt, but Docker Hub functions as a cache. If there have been no changes to `docker/` since the last available hash on Docker Hub, then the build will just use the images from Hub.
This sets us up to rebuild Docker images and uses them in later stages in the same build. This is not yet enabled (see the commented out code in
DockerBuild.groovy.j2
. If the build is running onmain
, then the images are uploaded to Docker Hub automatically once the run is complete. To avoid landing a complicated infra PR all at once this mostly adds the scaffolding and a follow up PR will: 1. upload images to tlcpack instead of tlcpackstaging 2. dynamically determine the docker image to use based on the latest hash 3. always rebuild docker images if an updated one hasn't been uploadedcc @Mousius @areusch