Docker bump adds patch version

[lucacome]

Package ecosystem
Docker

Updated dependency
Alpine from 3.13 to 3.14.0

What you expected to see, versus what you actually saw
I expected it to be updated to 3.14, not 3.14.0

Images of the diff or a link to the PR, issue or logs
https://github.com/nginxinc/kubernetes-ingress/pull/1672/files

[hemberger]

This also happened to me today in smrealms/smr#1104

Bumps nginx from 1.21-alpine to 1.21.1-alpine.

[lucacome]

This happened today nginx/kubernetes-ingress#1752

Bump golang from 1.16-alpine to 1.16.6-alpine and it's been on 1.16 for months.

[lucacome]

Is anybody looking into this? It's rather annoying...

[hemberger]

This just happened to me for a github-actions dependency as well: smrealms/smr#1108

Bumps codecov/codecov-action from 1 to 2.0.1.

[asciimike]

If you ignore patches, would that be sufficient? Or are there cases where you want patches but not these patches?

[hemberger]

My understanding was that dependabot is supposed to retain the specificity of the version, i.e. if you only specify a major version, it would only PR to bump to the next major version (similarly with the minor version).

Examples of what I'm expecting:

• Bump nginx from 1 to 2
• Bump nginx from 1.2 to 1.3
• Bump nginx from 1.2.3 to 1.2.4

By increasing the specificity of the version string, dependabot is changing the author's intentions. I feel like this was something that changed recently (in the past few months?), unless I'm mistaken.

[lucacome]

what @hemberger said 🙂 I think the behavior was to match the version until not long ago, and from the other issue it seems like the logic is still there in main

dependabot-core/docker/lib/dependabot/docker/update_checker.rb

Lines 120 to 123 in 7f03508

	# Check the precision of the potentially higher tag is the same as the
	# one it would replace. In the event that it's not the same, check the
	# digests are also unequal. Avoids 'updating' ruby-2 -> ruby-2.5.1
	return false if old_v.split(".").count == latest_v.split(".").count

[lucacome]

I didn't see it for a while but looks like it's still happening nginx/kubernetes-ingress#2050

[lucacome]

Just a friendly ping to check if this is being looked at or planned.

[jurre]

Just a friendly ping to check if this is being looked at or planned.

I don't think anyone is currently looking into this, but we're working on getting a better grip of our issue backlog and process around fixing bugs like these. I get that's a frustrating answer that doesn't help you right now, but I hope it will allow us to give a better answer around when we plan to look into this in the future.

[DasSkelett]

This has essentially the opposite effect of what dependabot wants to achieve: instead of always having an up to date base system because every image build automatically pulls in the latest base image, you end up with an outdated one until dependabot runs again. Running dependant on a monthly schedule, this gets significant. And creates a lot of useless noise.

Of course, for projects with very infrequent commits/builds the current behaviour might help, explicitly triggering a rebuild with an update of the base image where it wouldn't have happened otherwise for quite a while.
But one could still make use of this by explicitly specifying the PATCH or similar, whereas you cannot disable it for the other way around currently.

[hemberger]

Just wanted to add a comment that this is still an issue: smrealms/smr#1377

Actual:

Bumps nginx from 1.21-alpine to 1.23.0-alpine.

Expected:

Bumps nginx from 1.21-alpine to 1.23-alpine.

Thanks again for providing such a great tool! Hope this can get fixed eventually. :)

[deivid-rodriguez]

Hi! Just run into this myself, annoying indeed 😅.

I will provide a PR shortly, stay tuned!

[deivid-rodriguez]

#6170 should fix this!