Failed to pull image "jupyterhub/k8s-network-tools:d6340ab"

[manics]

Using JupyterHub version v0.7-be3d3b7 https://jupyterhub.github.io/helm-chart/jupyterhub-v0.7-be3d3b7.tgz

jupyterhub/k8s-network-tools:d6340ab isn't on Docker Hub, the most recent tag is 81c2613 from 7 days ago

[consideRatio]

Woops!

The desired behavior when a new chart is published is unclear to me, but something is wrong right now. Perhaps we should either...

1. Ensure one image tag is pushed for every image maintained by us, such as k8s-network-tools
2. Ensure we set the generated values.yaml file to utilize the latest available tag automatically.
3. Manually update the values.yaml file (instead of using a script) to utilize a certain image tag.

Here are some other images i looked at for comparison:

• https://hub.docker.com/r/jupyterhub/k8s-image-awaiter/tags/
• https://hub.docker.com/r/jupyterhub/k8s-pod-culler/tags/
• https://hub.docker.com/r/jupyterhub/k8s-network-tools/
• https://hub.docker.com/r/jupyterhub/singleuser/tags/

It seems like we are pushing tags only when the images change (not using option 1).

So what went wrong, did we update the k8s-network-tools image but failed to push it, or did we simply update the tag in values.yaml without reason?

For reference, it is the task of the chartpress repo to build and push images to dockerhub. I suspect the recent commit Make images optional is related.

@minrk or @jacobtomlinson - got insights about this? I have not used the chartpress repo myself.

[minrk]

81c2613 is the tag that it should be using, so it's not a failed push, it's putting the wrong tag in the chart. d6340ab is a well-outdated value that should't be used, but wasn't pushed due to a now-fixed bug in chartpress that got the wrong tags. I'm trying to figure out how this would happen because when I run chartpress locally, I get the right tags. I've opened #621 which shouldn't change any behavior, but ought to help debug issues like this.

I don't believe the 'make images optional' change is relevant because it only affects the case where chart['images'] is undefined, which would result in a KeyError prior to the change and a failed build. That doesn't happen for this repo.

[minrk]

I found it. And it's fixed by #621. The shallow clones Travis does by default resulted in misidentifying the latest commit for the image directories, which in turn results in the wrong tags being assigned to some images.