Failure to pull latest private image uses cached image instead

We ran into a situation where auth was failing to pull from a private registry. We already had pulled the image previsouly so it was cached. We had pull: true set.

We pushed an updated version of a tag to our registry. Drone was not pulling it due to auth failure, which I would expect. But the auth failure was not in logs and Drone continued to run tests from the cached image, which I would not expect. So we thought Drone was ignoring pull: true for some reason. We later “updated” our registry auth (we remember it had changed) in Drone and everything started to work as expected.

So given:

  • registry credentials are provided
  • Drone is not able to auth
  • pull: true is set

I would expect Drone to fail, even if it had previously downloaded the image.

Just wondering if expectation I have makes sense or if there is a reason for the way it behaves now. If it seems like a valid expectation I don’t mind creating an issue to track it.

Thanks!

Good question. I like that drone will fallback to the local cache if it cannot reach dockerhub for some reason. This can also be important when running drone exec locally when don’t have a network connection … yes, I run drone exec from airplanes :slight_smile:

Maybe we can find a way to return a warning, similar to when the yaml verification fails. It doesn’t fail the build, but displays a warning to the user.

I think having feedback (a warning) as you suggest would be useful and may be enough. Since we had no idea (until remembering our creds changed recently) that it was failing to auth we just kept trying to get it to work.

Should I open an issue for this? Would it be to drone/drone or drone/drone-ui or both?