Consider using Renovate

[nzakas]

This app helps keep dependencies up to date:
https://github.com/marketplace/renovate

What do we think about including this in the repo?

[aladdin-add]

just a note: the default commit tag is a liitle different than ours. we may need update eslint-release to allow the format chore(deps): xxx.

[bmish]

Very much in favor of using an automatic dependency updater.

I do like Renovate, although Dependabot has become my default automatic dependency updater since GitHub acquired and integrated it. Any reason to choose one over the other?

[ljharb]

Renovate is awesome and far more configurable, and dependabot imo is junk, altho it’s slowly getting better over time.

You can configure any commit message convention you like.

[nzakas]

I just can’t stand the millions of one-off dependabot update PRs. I’m open to anything that gets us out of that situation.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[nzakas]

I’m testing Renovate on my own repos. Will report back with feedback.

[nzakas]

TSC Summary: This issue proposes setting up Renovate on ESLint repos. Renovate prefers to pin all dependencies and send pull requests to update each dependency individually. It can be a bit noisy, but it would ensure that we are regularly updating dependencies, which is something we don't do very well right now.

TSC Agenda: Should we enable Renovate on the org?

[ljharb]

Note you can customize the config to group updates if you like, much more granularly than any other alternative I’m aware of.

[btmills]

We accepted this change in the 2023-02-09 TSC meeting. I'm working on release-please first and will try to get to this next, but anyone else who's interested should feel free to take it before me!

[rarkins]

Hi, the Renovate team would be happy to help you get onboarded.

Here's what I recommend:

1. An admin of the eslint org should go to https://github.com/apps/renovate and Install into this org. Use "Select repositories" and select this repo only
2. You will then see a single onboarding Pull Request like this: Configure Renovate renovate-reproductions/eslint#1
3. I recommend you modify the default slightly to enable Dependency Dashboard Approval like here: https://github.com/renovate-reproductions/eslint/blob/main/renovate.json
4. Merge the PR

You will then get a single "Dependency Dashboard" issue like renovate-reproductions#2. No further PRs will be sent unless a maintainer requests them on-demand from that Issue.

In other words, my recommendation above will result in only 1 (merged) PR and one open Issue.

Observations:

• You are using "major" ranges in most dependencies, e.g. @v3 in actions or ^1.0.0 in npm
• No lock files present for npm
• There's a lot of outdated major updates pending

You don't need to change anything, and Renovate can work happily with this approach, but in future you could consider:

• Pinning GitHub actions to SHAs and exact versions (e.g. v3.0.1 not v3)
• Pinning npm devDependencies to non-ranges to reduce the chance of accidental breakages from upstream bugs

[HonkingGoose]

Pinning GitHub actions to SHAs and exact versions (e.g. v3.0.1 not v3)

Easiest way to pin your GitHub Actions is to add helpers:pinGitHubActionDigests ¹ to the extends array in your renovate.json config file:

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:base",
        ":dependencyDashboardApproval",
        ":semanticCommitScopeDisabled",
+       "helpers:pinGitHubActionDigests"
    ]
}

Renovate will then create a PR that pins all the actions.

The GitHub Docs says: ²

• Pin actions to a full length commit SHA

Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.

General "noise reduction" strategies

When you start allowing Renovate to create update PRs automatically, you may use noise reduction strategies, for example: ³

• Package grouping
• Scheduling when Renovate is allowed to create PRs (The GitHub-hosted Renovate app always update current PRs, regardless of schedule)
• Automerging update PRs for linters like prettier

Footnotes

1. https://docs.renovatebot.com/presets-helpers/#helperspingithubactiondigests ↩

2. https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions ↩

3. https://docs.renovatebot.com/noise-reduction/ ↩

[ljharb]

fwiw i don’t think it’s actually a good idea to pin actions to a sha for the same reason it’s not a good idea to pin a dependency on a single version number, but I’ll let the eslint folks make that decision.

[nzakas]

@btmills are you still interested in implementing this?

[aladdin-add]

@nzakas I will give it a try.

[nzakas]

@aladdin-add thanks!

[HonkingGoose]

@aladdin-add I'd recommend this configuration in your renovate.json file:

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:recommended",
        ":dependencyDashboardApproval",
        "helpers:pinGitHubActionDigests",
        ":semanticCommitTypeAll(ci)"
    ]
}

• config:recommended gives you the Renovate maintainers recommended behavior for many things
• :dependencyDashboardApproval creates a "Dependency Dashboard Issue" where you approve any Renovate update beforehand
• helpers:pinGitHubActionDigests pins your GitHub Actions to a SHA checksum, which is what GitHub recommends you do
• :semanticCommitTypeAll(ci) makes it so all Renovate PR's start with the ci(deps) text

[aladdin-add]

config:base gives you the Renovate maintainers recommended behavior for many things
:dependencyDashboardApproval creates a "Dependency Dashboard Issue" where you approve any Renovate update
beforehand

sgtm! 👍

helpers:pinGitHubActionDigests pins your GitHub Actions to a SHA checksum, which is what GitHub recommends you do

I prefer not to use it - to start with, I prefer to start with a minimal configuration, as currently we don't do that, I think that's something we can consider in the future.

:semanticCommitTypeAll(ci) makes it so all Renovate PR's start with the ci(deps) text

All the eslint repos follow conventional commits, but currently does not use scopes: https://eslint.org/docs/latest/contribute/pull-requests#step-2-make-your-changes.
Is there a more appropriate option for us?

[HonkingGoose]

GitHub recommends you pin your actions

I prefer not to use it - to start with, I prefer to start with a minimal configuration, as currently we don't do that, I think that's something we can consider in the future.

I'll just say (again) that GitHub really recommends you pin your actions: ¹

• Pin actions to a full length commit SHA

  Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.

With that warning out of the way: it's your repository, and your rules. 😉

Drop scopes

All the eslint repos follow conventional commits, but currently does not use scopes: https://eslint.org/docs/latest/contribute/pull-requests#step-2-make-your-changes.
Is there a more appropriate option for us?

Oh, I did not see you're not using scopes... 😄 Here's a better idea: ²

Changing the Semantic Commit scope

You can set your own word for the scope if you don't like the default "deps" scope.
For example, to set the scope to "package", add the preset ":semanticCommitScope(package)" to your extends array:

{
  "extends": [":semanticCommitScope(package)"]
}

To remove the semantic commit scope, so Renovate uses chore: instead of chore(deps):, add the ":semanticCommitScopeDisabled" preset to your extends array:

{
  "extends": [":semanticCommitScopeDisabled"]
}

New proposed config

Changes:

• Drop GitHub Action pinning
• Disable Conventional Commit scopes

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:recommended",
        ":dependencyDashboardApproval",
        ":semanticCommitTypeAll(ci)",
        ":semanticCommitScopeDisabled"
    ]
}

Footnotes

1. GitHub Docs, using third-party actions ↩

2. Renovate docs, Changing the Semantic Commit scope ↩

[ljharb]

Pinning your actions is harmful, because it prevents bug and security fixes from flowing into your CI. That GitHub recommends it shouldn’t hold much weight.

[HonkingGoose]

Pinning your actions is harmful, because it prevents bug and security fixes from flowing into your CI.

I assume you mean: prevents fixes from flowing into your CI automatically? Here's the sequence of events, when pinning:

1. User decides to let Renovate pin the action
2. Renovate creates a PR that pins all the actions to their latest current SHAs
3. User confirms SHAs belong to the correct repositories
4. User merges PR
5. Action gets security update
6. Renovate sees update and creates PR
7. User reviews PR, checks SHA, read changelogs
8. User merges PR

Say a users uses the standard version syntax, like actions/checkout@v3. They'll always use the latest version in the v3 range. They'll miss out on some guarantees about the actual version they're using. Those users aren't reading the changelogs, and they're not getting a feel for the pulse of the source repository for the action.

Am I right in thinking you value getting your action updates now and automatically higher than any SHA-pinning guarantees?

That GitHub recommends it shouldn’t hold much weight.

I think the creators of GitHub Actions probably know best how end-users should use and secure it. If their docs say: pin your actions, I'm happy to assume that's the best thing to do for most users. 😄

[ljharb]

Yes, preventing the automatic flow of fixes is harmful. Using renovate or similar to keep actions updated mitigates this, but at the cost of tons of PR noise.

I think the creators of GitHub Actions probably know best how end-users should use and secure it

This is almost always a flawed assumption; the creators of a thing aren't guaranteed to know how to use it best - also, the creators of github actions aren't likely the ones who wrote those docs - i'd bet that was the security team.

[nzakas]

I think we're missing some context in this discussion: GitHub recommends pinning against an action SHA for third party actions. And I agree, if we end up using actions from untrusted sources, this is probably the way to go.

I don't think pinning ALL actions to a SHA makes sense for the reasons @ljharb mentioned.

[JoshuaKGoldberg]

A new note: I'd recommend using Renovate's minimumReleaseAge feature. It allows for configuring how many days to wait after a new package version before sending its update PR. This is useful in the case of maliciously published packages, to let the community vet them first.

[nzakas]

@JoshuaKGoldberg do you want to explore setting it up for this repo?

[JoshuaKGoldberg]

Can do! I'll put it on my task list for this week. Will edit this comment if I run over.

Edit: this week 🙃

[nzakas]

Just a heads up that I enabled Renovate in the repo. I believe it won't start creating PRs yet.

[JoshuaKGoldberg]

I put some more implementation questions in the description of #17567.