Avoid bumping to versions which are not Long Term Support (LTS) version

[dmabamboo]

Hi,

Is there a way to avoid dependabot offering non-LTS versions of Node.JS? We don't want to run any non-LTS versions but don't want to miss out on updates to the LTS version.

Regards, Daniel

[greysteil]

Hey Daniel,

Interesting question. Is there a particular PR that's getting it wrong? If you link to that (you can email me on support@dependabot.com) then I'll have a think about specially how Dependabot could do better there.

[dmabamboo]

Sorry @greysteil I didn't follow it up, sent you an email as requested. Regards, Dan

[lucas42]

Hi,    I was wondering whether you came to any conclusions from your email discussion on this? I'm interested in the same thing, but didn't want to raise something new if it's already been looked into.

Cheers,        Luke

[rebelagentm]

@lucas42 Grey is no longer working on Dependabot (he's moved to security in general at GitHub), but I looked back through that support conversation, and I believe this was the conclusion:

• It would be tricky from a Dependabot standpoint to have something specific to Node and LTS, but Grey didn't shut the door completely to the possibility.

That being said, the team is currently pretty swamped scaling Dependabot for GitHub, so it would be some time before we could get to looking into this. Since there is interest in this, I'm going to re-open this issue so we have it on our list.

[lucas42]

Thanks!
I'm only using dependabot for some personal projects to begin with, so happy to upgrade to the latest and greatest of each release.

But if we were to roll it out across various team at work, this would be a must-have feature.

Cheers

[rebelagentm]

Thanks for the feedback, @lucas42! We'll keep that in mind once we're able to turn our attention back to working on enhancements like this.

[oittaa]

Just encountered this issue when dependabot tried to update node from 14.16.0-alpine3.13 to 15.11.0-alpine3.13

https://github.com/oittaa/firebase-docker/pull/1

[TanguyChiffoleau]

An implementation of such a feature would be so great

[asciimike]

Can you use ignore conditions to ignore odd versions, e.g.:

version: 2
updates:
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: "node"
        versions: ["15.x", "17.x", ...]

I recognize that it's not automatic (e.g. we can't automatically ignore odd versions), but it only requires an update every six months (at most, you could even drop in the first few now...), which feels better than always closing the PR.

[domenic]

That doesn't work for the six month period (like the one we're in now with Node v16) where an even version is "current" but not yet promoted to "active LTS".

[asciimike]

@domenic thanks for following up; is there a way to know if a version is LTS purely by looking at it, or would we have to add code to look at https://nodejs.org/en/about/releases/ and add six months (or manually update it every several years)?

Seems like that the ignore would technically work, it would just have to be manually removed after the six month period.

[domenic]

I don't see any way just from the version string (or any variant of it). I mean, you could just use the lts-buster-slim tag but then you wouldn't get dependabot updating your versions; you'd just get whatever the latest LTS is whenever you redeploy. (Which might work for some use cases.)

If you can insert some code into the pipeline then it's certainly possible. The most authoritative way is to consult the "lts" key in https://nodejs.org/dist/index.json . Googling around I found people who have done similar things in https://github.com/nodejs/Release/issues/295 .

[zwik]

I understand the problem but I think we manually want to control if we want to upgrade to a new major version. I think the same might be true for other images where breaking changes might be in order. This would work for me at least. In that case ignoring major versions like @asciimike is doing would be perfectly fine.

[djdembeck]

Seeing this as well - I'm using distroless 14 image, but dependabot is trying to bump the builder layer from 14 to 16, which wouldn't match versions in the build: https://github.com/djdembeck/audnexus/pull/13

[huan]

@asciimike as you said, it would be great if we can

use ignore conditions to ignore odd versions

Instead of hard coding it, can we add a new ignore: semver-odd-minor, or we can pass the version number to a custom script?

[rafaelmaeuer]

Can you use ignore conditions to ignore odd versions, e.g.:

version: 2
updates:
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: "node"
        versions: ["15.x", "17.x", ...]

I recognize that it's not automatic (e.g. we can't automatically ignore odd versions), but it only requires an update every six months (at most, you could even drop in the first few now...), which feels better than always closing the PR.

Nice idea, but nor working for me, still getting bump node from 16.14.2-alpine to 17.8.0-alpine PRs

From Dependabot-Log:

updater | INFO <job_329466396> Checking if node 16.14.2-alpine needs updating
updater | INFO <job_329466396> Ignored versions:
updater | INFO <job_329466396>   15.x - from .github/dependabot.yml
updater | INFO <job_329466396>   17.x - from .github/dependabot.yml
...
updater | INFO <job_329466396> Latest version is 17.8.0-alpine
updater | INFO <job_329466396> Pull request already exists for node with latest version 17.8.0-alpine

[zwik]

I recently found this out as well but forgot about this particular issue, I think it's quite a new addition.

[rafaelmaeuer]

I also tried using update-types: ["version-update:semver-major"]

version: 2
updates:
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "daily"
    ignore:
      - dependency-name: "node"
        update-types: ["version-update:semver-major"]

from specifying-dependencies-and-versions-to-ignore, but it seems to disable PRs for node completely...

[domenic]

We're now in a dangerous 5-month period, where until 2022-10-25, the latest even version number of Node.js is v18, but it's not yet LTS.

So any hacks which rely on ignoring odd version numbers of Node will not work. Dependabot will relentlessly lob PRs over the wall at you with v18 revisions. And, any hacks which rely on ignoring v18, will need to be manually reverted in late October.

[jeffwidman]

I edited the issue to reflect the general idea of bumping docker images from one LTS release to the next.

This applies not only to NodeJS, but also other images in the docker ecosystem. For example, only bumping ubuntu from one LTS release to the next... ie don't try to bump 18.04 to 20.04, but only to 22.04.