Publish command: call docker hub api to check the tag was registered #11654
Conversation
alafanechere
requested review from
cgardens,
davinchia,
sherifnada,
timroes and
supertopher
Co-authored-by: Davin Chia <davinchia@gmail.com>
| # Checking it the image was successfully registered on DockerHub | ||
| TAG_URL="https://hub.docker.com/v2/repositories/${image_name}/tags/${image_version}" | ||
| DOCKERHUB_RESPONSE_CODE=$(curl --silent --output /dev/null --write-out "%{http_code}" ${TAG_URL}) | ||
| if [[ "${DOCKERHUB_RESPONSE_CODE}" == "404" ]]; then |
There was a problem hiding this comment.
some questions:
1.is this API immediately consistent, or eventually consistent? if the latter,we may start failing a lot of builds for transient reasons
2. what is the expectation from an engineer once they run across this error? are they expected to republish? bump the version again? If their build fails, what is their actionable next step?
There was a problem hiding this comment.
- I don't know. As of today the connector I published that led to a 404 on the dockerhub still remains 404. I could add a
sleepfor 5 seconds in case there's a small delay before the tag is available on the API after the push. - Bumping again is the suggested action. Republishing won't work because the image is registered but not discoverable with the API.
There was a problem hiding this comment.
could you test #1 please? i just want to make sure this doesn't suddenly start introducing a ton of failures for a case which is 1% of the time.
if we want to move forward, then for 2 could you add that in the log message? (the action the dev needs to take)
There was a problem hiding this comment.
I tested to run a publish workflow on destination-e2e which latest version was not published. It worked. I also tried with the 404 URL to test the behavior in case of bad API response, it also worked as expected: the job failed and the message I set is echoed.
alafanechere
deleted the
augustin/publish-command/check-dockerhub-registered
branch
| # see the description of this PR to understand why this is needed https://github.com/airbytehq/airbyte/pull/11654/ | ||
| sleep 5 | ||
| TAG_URL="https://hub.docker.com/v2/repositories/${image_name}/tags/${image_version}" | ||
| DOCKERHUB_RESPONSE_CODE=$(curl --silent --output /dev/null --write-out "%{http_code}" ${TAG_URL}) |
There was a problem hiding this comment.
I wonder if this step would benefit from some retry? does dockerhub fail in a way that a retry shortly after would be useful? the man page for curl has a fairly deep set of retry options if that is interesting to you
cool use of pulling the HTTP code here ☝️
|
@alafanechere, this check does not work for private repository such as |
What
In some rare situations, it can happen that a docker tag was successfully published but that the DockerHub does not register this tag, making the tag not available in the UI nor in the API we call to check if the image exists.
This problem happened for
source-bing-ads:0.1.4:https://hub.docker.com/v2/repositories/airbyte/source-bing-ads/tags/0.1.4(related Slack conversation for fellow Airbyters)
How
I want to detect this error early in our release process by making the
/publishcommand fails if this problem occurs.It will allow us to detect it before merging a connector PR and avoid breaking the Airbyte release.