-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Run check-that-image-builds-quickly job only in canary #53212
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
Run check-that-image-builds-quickly job only in canary #53212
Conversation
Backport failed to create: v3-0-test. View the failure log Run details
You can attempt to backport this manually by running: cherry_picker d2fc753 v3-0-testThis should apply the commit to the v3-0-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continue |
|
Actually the reason for that was different - the image is building slightly longer now after building python from scratch and we were supposed to increase the timeout to 15 minutes with @aritra24 - but it slipped through the cracks I guess. |
|
It slipped through the cracks that we should change both - timeout in the message and timeout-minutes :) |
The apache#53212 changed the quick-image-build check to only run on canary build, but this was not the intention - and the image started to fail because of timeout minutes were too short after we added python building from sources. This PR fixes it "properly" - changes timeout minutes to be slightly longer than the timeout (900 seconds) we specify in build command and brings back building the image on regular PRs.
|
Proper fix here #53227 |
The apache#53212 changed the quick-image-build check to only run on canary build, but this was not the intention - and the image started to fail because of timeout minutes were too short after we added python building from sources. This PR fixes it "properly" - changes timeout minutes to be slightly longer than the timeout (900 seconds) we specify in build command and brings back building the image on regular PRs.
The #53212 changed the quick-image-build check to only run on canary build, but this was not the intention - and the image started to fail because of timeout minutes were too short after we added python building from sources. This PR fixes it "properly" - changes timeout minutes to be slightly longer than the timeout (900 seconds) we specify in build command and brings back building the image on regular PRs.
…inutes (#53227) The #53212 changed the quick-image-build check to only run on canary build, but this was not the intention - and the image started to fail because of timeout minutes were too short after we added python building from sources. This PR fixes it "properly" - changes timeout minutes to be slightly longer than the timeout (900 seconds) we specify in build command and brings back building the image on regular PRs. (cherry picked from commit 5579edd) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
…inutes (#53227) (#53230) The #53212 changed the quick-image-build check to only run on canary build, but this was not the intention - and the image started to fail because of timeout minutes were too short after we added python building from sources. This PR fixes it "properly" - changes timeout minutes to be slightly longer than the timeout (900 seconds) we specify in build command and brings back building the image on regular PRs. (cherry picked from commit 5579edd) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
…he#53227) The apache#53212 changed the quick-image-build check to only run on canary build, but this was not the intention - and the image started to fail because of timeout minutes were too short after we added python building from sources. This PR fixes it "properly" - changes timeout minutes to be slightly longer than the timeout (900 seconds) we specify in build command and brings back building the image on regular PRs.
this job needs
push-early-buildx-cache-to-github-registryjob and docker login, these write access only available in repo not from forks.^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.