Use renovate to bump base image refs

[ralphbean]

And set automerge to true to put this on autopilot.

[webbnh]

Looks OK to me.

However, in general, I'm not a fan of specifying the SHA hash on the container image references. I realize that I'm at odds with the increasingly prevailing attitude on this, but the practice tends to generate a lot of noise. On the other hand, enabling automerge will allow us to ignore the updates...which largely ameliorates the noise problem but kind of defeats the purpose of using the hash in the first place!

So, while I think using automerge is very attractive (and I'm inclined to support that), I would be inclined to omit the hash. (What exactly are we trying to accomplish by using the hash and would using a semantic version tag (instead of latest), instead, be a better approach?)

[ralphbean]

(What exactly are we trying to accomplish by using the hash

Trying to accomplish deterministic updates. When we build anew, we know that we're building on a new base image, vs not. We know the last time we updated our base image easily from source, rather than trying to go divine it from the registry history.

would using a semantic version tag (instead of latest), instead, be a better approach?)

I've never tried it. Let's try it and see if renovate bumps it like we want it to.

[ralphbean]

/retest sync2jira-sync-page-on-pull-request

[webbnh]

What exactly are we trying to accomplish by using the hash

Trying to accomplish deterministic updates. When we build anew, we know that we're building on a new base image, vs not. We know the last time we updated our base image easily from source, rather than trying to go divine it from the registry history.

What specifying the hash accomplishes is the ability to re-build a given Git commit (assuming that the image referenced by the hash is still available when the rebuild is attempted). It really doesn't do much in terms of a new build (except to record what was used, in case we want to try to recreate it). (In terms of knowing what the last update was, we can tell that by looking at the previous image, which we'll probably end up doing even if we reference it by its hash.)

We might hope that the image targeted by the hash has somehow been blessed and is therefore "good". But, frankly, we hope the same of the image referenced by latest, so the hash doesn't gain us anything there, either.

I can see a scenario in which the hash gets updated asynchronously with respect to the build and where the image repository doesn't get updated (such that latest isn't actually the "latest") -- in that case, the build would either pull the referenced image or would fail -- and that would be a benefit; however, if the image repository were being properly managed (such that latest was an acceptable image), then we wouldn't care.

would using a semantic version tag (instead of latest), instead, be a better approach?

I've never tried it. Let's try it and see if renovate bumps it like we want it to.

Renovate can be configured to manage the image reference as either a semantic version tag or a hash; in both cases, it should update the value when there is a new referent available. The only real difference, if you trust in the concept and implementation of semantic versioning, is that using the hash requires frequent updates to the build files while using the semver tag only requires updates when the current version changes (and, if you reference a minor version the changes are infrequent, and if you reference a major version, they are very infrequent).

Nevertheless, if we trust Renovate, we can let it do the update without human involvement, in which case we just have to monitor the notifications (for failures), and we don't have to do anything on the successes. But, there would be less noise if we used semvers rather than hashes.