Stop using docker manifest to check for image presence #17883
Merged
potiuk merged 1 commit intoSep 21, 2021
Merged
Conversation
Member
Author
|
One more fix to accidentally failing tests . Such a 🤦 on me. |
75041d2 to
e9116b4
Compare
Member
Author
|
It were bad - downgraded constraints (the downgrade should be fixed by #17939 ) |
0ex-d
approved these changes
Sep 4, 2021
c4e9391 to
3fb4213
Compare
3369726 to
916dcec
Compare
Member
Author
|
I removed completely the "experimental" flag @uranusjr - this only caused troubles and I actually need to pull the image anyway (for verification) once it is ready - so rather than checking if image is there via |
916dcec to
0abef5f
Compare
Member
Author
|
Rebuilding to see if the failures are transient. |
d086793 to
55d4a9b
Compare
Member
Author
|
Just MSSQL tests wich has to be fixed anywyay. But it's good |
6d0c620 to
5015b58
Compare
Member
Author
|
All Green. This will remove another source of random CI failures. |
We need to set the "experimental" flag in CI in order to use `docker manifest` command to check for presence of the images in ghcr.io. In order to use them we need to enable experimental features via ~/.docker/config.json. Sometimes, very rarely, we had the case that the config file got broken and the problem turned out to be that we tried to do this experimental replacement in parallel by several running "wait image" commands (:facepalm: here for myself) that were apparenlty overriding the same config.json at the same time in non-atomic way, which (very rarely) led to corrupted file. However for quite some time we pulled the image immediately after it was available, in order to verify the image, so rather than checking if the image is there via manifest, we can simply pull the image and effect will be the same - if it fails, the image is not there, if it has been pulled - we can immediately verify it. We do not need experimental flag at all for that so no messing around with .docker/config.json is needed at all.
5015b58 to
c766e4b
Compare
ashb
approved these changes
Sep 21, 2021
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Sep 22, 2021
The change apache#17883 missed re-tagging images after downloading which caused unnecessary image rebuilding for PRs as well as using wrong image for doc building - previous version of docs were used when building docs!
potiuk
added a commit
that referenced
this pull request
Sep 22, 2021
The change #17883 missed re-tagging images after downloading which caused unnecessary image rebuilding for PRs as well as using wrong image for doc building - previous version of docs were used when building docs!
This was referenced Sep 22, 2021
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Sep 22, 2021
Recently we had a problem that our CI got broken because pulled images were not tagged properly after apache#17883 missed image tagging. This has been fixed in apache#18433 but the problem is that this might happen in the future and mignt not get noticed on time. This PR prevents from similar situations happnening. Whenever we try to run doc building or tests we set --pull policy to never for both docker and docker compose which should simply fail if the images were not pulled and tagged properly rather than fail over to pulling latest `main` image.
potiuk
added a commit
that referenced
this pull request
Sep 22, 2021
Recently we had a problem that our CI got broken because pulled images were not tagged properly after #17883 missed image tagging. This has been fixed in #18433 but the problem is that this might happen in the future and mignt not get noticed on time. This PR prevents from similar situations happnening. Whenever we try to run doc building or tests we set --pull policy to never for both docker and docker compose which should simply fail if the images were not pulled and tagged properly rather than fail over to pulling latest `main` image.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We need to set the "experimental" flag in CI in order to use
docker manifestcommand to check for presence of the imagesin ghcr.io. In order to use them we need to enable experimental
features via ~/.docker/config.json.
Sometimes, very rarely, we had the case that the config file
got broken and the problem turned out to be that we tried
to do this experimental replacement in parallel by several
running "wait image" commands (🤦 here for myself)
that were apparenlty overriding the same config.json
at the same time in non-atomic way, which (very rarely)
led to corrupted file.
However for quite some time we pulled the image immediately
after it was available, in order to verify the image,
so rather than checking if the image
is there via manifest, we can simply pull the image
and effect will be the same - if it fails, the image is not
there, if it has been pulled - we can immediately verify
it. We do not need experimental flag at all for that
so no messing around with .docker/config.json is needed
at all.