Renovate: Upgrades to the wrong docker tag

[Flydiverny]

What Renovate type are you using?
Renovate GitHub App

Describe the bug
Picks the wrong docker tag

- FROM nginx:1.12-alpine
+ FROM nginx:1.15-alpine-perl

Did you see anything helpful in debug logs?

...
DEBUG: FROM line
{
  "lineNumber": 20,
  "fromLine": "FROM nginx:1.12-alpine"
}
DEBUG: Dockerfile FROM
{
  "depName": "nginx",
  "currentValue": "1.12-alpine"
}
...
DEBUG: docker.getDependencies()
{
  "fullname": "nginx"
}
....
DEBUG: 1 result(s): 1.15-alpine-perl (nginx)(dependency="nginx")
...
          {
            "depName": "nginx",
            "currentDepTagDigest": "nginx:1.12-alpine",
            "currentDepTag": "nginx:1.12-alpine",
            "currentValue": "1.12-alpine",
            "currentFrom": "nginx:1.12-alpine",
            "purl": "pkg:docker/nginx",
            "lineNumber": 20,
            "fromPrefix": "FROM",
            "fromSuffix": "",
            "updates": [
              {
                "fromVersion": "1.12",
                "toVersion": "1.15",
                "newValue": "1.15-alpine-perl",
                "newMajor": 1,
                "newMinor": 15,
                "updateType": "minor",
                "isSingleVersion": true,
                "newVersion": "1.15"
              }
            ],
            "warnings": [],
            "sourceUrl": null,
            "releases": [
              "1.12",
              "1.13",
              "1.13",
              "1.14",
              "1.14",
              "1.15",
              "1.15"
            ]
          }
        ]
...

To Reproduce
Steps to reproduce the behavior (not tested):

1. Create repository with Dockerfile with nginx:1.12-alpine
2. Configure renovate base configuration
3. Check renovate PR

Expected behavior
Expected it to update to nginx:1.15-alpine image.

---

I suspect it's just picking the last occurrence of the 1.15 tag while we probably want it to respect the suffix.

[rarkins]

Actually it's because it splits the tag based on hyphens and then uses the first chunk as the version and the second chunk as the suffix to match. In this example the second chunk is "alpine" so it thinks it's a match. Docker tags are a mess and I forget why we did it that way for now, I think I'll revert back to comparing chunks 2+ together instead, which would stop this mistake. Thanks for raising.

[Flydiverny]

I can totally understand docker tags being a mess to handle!

Perhaps the could be some config for it? I suppose semver wise suffixes might be confusing to deal with. Comparing both chunks would cover this case, but I suppose it would prevent something like a 1.15-rc upgrading to 1.15.

[rarkins]

The good news is that there is a starting point for making it configurable now.

By default, we use a versioning scheme we defined called "docker" that assumes the first part of the tag is semver (or semver-like, because we also allow versions like 16.04 with leading zeroes) and the second part of the tag after the hypen is some form of "platform" restriction, e.g. -alpine. You hit something which is kind of a bug in the way we're parsing the platform side and will be fixed.

So by default, if an image had tags 1.15-rc and 1.15 then you would not get an upgrade for that, only if something like 1.16-rc came out. But let's say you use a package that uses semver properly, e.g. tags like 1.0.0-alpha.1. In that case you would want to be updated to 1.0.0-beta.1 or 1.0.0 when they come out, so you could add a packageRule that sets "versionScheme": "semver" to override our default versionScheme of "docker".

In this case though, it's simply a bug.

[renovate-bot]

:tada: This issue has been resolved in version 13.158.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: