renovatebot / renovate

Home of the Renovate CLI: Cross-platform Dependency Automation by Mend.io
https://mend.io/renovate
GNU Affero General Public License v3.0
17.18k stars 2.24k forks source link

Renovate suggesting upgrading to an older docker image #4827

Closed hairyhenderson closed 4 years ago

hairyhenderson commented 4 years ago

What Renovate type are you using?

Hosted, on GitHub.

Describe the bug

In https://github.com/qlik-oss/dockerfiles/pull/154, renovate is attempting to "upgrade" the python:3.8.0-alpine3.10 image to python:3.8.0b1-alpine3.10, which is an older beta version of python:3.8.0-alpine3.10.

Did you see anything helpful in debug logs?

(here: https://app.renovatebot.com/dashboard#github/hairyhenderson/dockerfiles/113814275)

I can't see anything that useful other than a hint that renovate does think it needs to be updated to 3.8.0b1:

{
            "depName": "python",
            "currentValue": "3.8.0-alpine3.10",
            "datasource": "docker",
            "managerData": {
              "lineNumber": 51,
              "fromPrefix": "FROM",
              "fromSuffix": "AS pypackages"
            },
            "depType": "stage",
            "updates": [
              {
                "fromVersion": "3.8.0",
                "toVersion": "3.8.0b1",
                "newValue": "3.8.0b1-alpine3.10",
                "newMajor": 3,
                "newMinor": 8,
                "updateType": "minor",
                "isSingleVersion": true,
                "newVersion": "3.8.0b1"
              }
            ],
            "warnings": [],
            "sourceUrl": null,
            "dockerRegistry": "https://index.docker.io",
            "dockerRepository": "library/python"
          },

To Reproduce

n/a

Additional context

I'm thinking the version comparison scheme is to blame here. In cases like this which may be ambiguous (since it's not a true server - it should arguably have been 3.8.0-b1), it may be best to also compare the age of the tags.

rarkins commented 4 years ago

We support pep440 versioning - which this is - but in this case we use our custom “docker” versioning to handle the platform suffixes and it’s not pep440-aware. Need to think of our regex versioning could be an alternative.

I’m not sure that date-based tag comparisons could ever be reliable enough to use unfortunately - could be wrong far more times than it helps.

hairyhenderson commented 4 years ago

I've just found this in the documentation - not sure how long it's been there, but it seems promising: https://docs.renovatebot.com/docker/#version-compatibility

I'll come back and close this if it indeed solves the issue 😉

hairyhenderson commented 4 years ago

@rarkins as a side-note, it might be useful if the debug logs could include which versionScheme was used - it might've tipped me off that it's a setting that can be changed 😉

hairyhenderson commented 4 years ago

Ok, yup - looks like configuring the versionScheme fixes this!

For completeness, I used a config like this (copy-pasted from the docs, even):

{
  "packageRules": [
    {
      "datasources": ["docker"],
      "packageNames": ["python"],
      "versionScheme": "pep440"
    }
  ]
}
ineentho commented 4 years ago

I don't think the above example will work very well - from my testing pep440 doesn't support the docker "compatibility" part (ie -alpine).

The example regex in the docs however seems to be working good - it seems to be working just like the docker versioning + it considers b1 as a prerelease.

  "packageRules": [
    {
      "datasources": ["docker"],
      "packageNames": ["python"],
      "versionScheme": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)(?<prerelease>[^.-]+)?(-(?<compatibility>.*))?$"
    }
  ]
rarkins commented 4 years ago

Regular pep440 indeed doesn’t support Docker suffixes like -alpine. Glad to hear that the regex works for you as intended. I think we should consider publishing this and any others into presets so they don’t need to be copy pasted and could be updated in future if necessary