build: configure Dependabot

[yeikel]

To keep our dependencies up to date and secure

See #225 to see why this is needed

See it in action : https://github.com/yeikel/action-semantic-pull-request/pulls

[amannn]

Hi @yeikel and thank you very much for this PR!

Unfortunately, Dependabot creates a lot of noise and the security analysis method it uses is broken by design.

These are the dependencies that this action currently uses in builds and that run in containers:

action-semantic-pull-request/package.json

Lines 25 to 31 in ff373f4

	"dependencies": {
	"@actions/core": "^1.10.0",
	"@actions/github": "^5.1.1",
	"conventional-changelog-conventionalcommits": "5.0.0",
	"conventional-commit-types": "^3.0.0",
	"conventional-commits-parser": "^3.2.4"
	},

We've recently updated all dependencies in the project. My current perspective is that the load of pull requests that Dependabot creates, causes much more trouble than what we gain from it.

Something like a quarterly dependency update where the relevant dependencies are checked in detail seems more useful to me.

If there is some configuration option for Dependabot where it creates a PR once every 3 months where it updates all dependencies in one batch, I think this could be a good compromise.

What do you think?

[yeikel]

Hi @yeikel and thank you very much for this PR!

Unfortunately, Dependabot creates a lot of noise and the security analysis method it uses is broken by design.

These are the dependencies that this action currently uses in builds and that run in containers:

action-semantic-pull-request/package.json

Lines 25 to 31 in ff373f4

	"dependencies": {
	"@actions/core": "^1.10.0",
	"@actions/github": "^5.1.1",
	"conventional-changelog-conventionalcommits": "5.0.0",
	"conventional-commit-types": "^3.0.0",
	"conventional-commits-parser": "^3.2.4"
	},

We've recently updated all dependencies in the project. My current perspective is that the load of pull requests that Dependabot creates, causes much more trouble than what we gain from it.

Something like a quarterly dependency update where the relevant dependencies are checked in detail seems more useful to me.

If there is some configuration option for Dependabot where it creates a PR once every 3 months where it updates all dependencies in one batch, I think this could be a good compromise.

What do you think?

Dependabot keeps dependencies up to date in general and it is not only concerned about security upgrades.

I think that it is important to keep dependencies up to date in general to get notified about new features and enhancements as well as be informed about deprecations and breaking changes as they happen.
For example, It is usually easier to migrate from a deprecated API than to do so after the API has been removed 3-4 releases later.

This is crucial to save development time as I personally find smaller upgrades easier to manage.

Generally, I think that waiting 3-4 months to update dependencies is not desirable in general and more so when new versions might come with bug fixes (or security upgrades). it is important to note that dependabot also leverages Github Security Advisories

Something like a quarterly dependency update where the relevant dependencies are checked in detail seems more useful to me.

Dependabot does not support this. The best we have is monthly and it'll still create separate upgrades if applicable. Dependabot tries to bundle dependencies where it is applicable

In general, it is a good practice to avoid bundling unrelated dependency upgrades together because it complicates reverts if they are needed. Small changes are usually better in general in my experience

[amannn]

I understand your perspective. I'd absolutely love a workflow with Dependabot where I'm alerted immediately if a dependency is used in a way that poses a security risk—please don't get me wrong. Unfortunately, as outlined in the blog post I've mentioned above, this is rarely the case.

I'm sure your situation is similar, but I only have limited time and I can't afford to keep up with a lot of updates that will likely not change anything meaningful for the project.

These are the options I currently see:

1. Wait for grouped updates of Dependabot and enable it then.
2. (In the meantime) Update dependencies sporadically, as necessary.
3. Install dependencies as part of the workflow without a lockfile, so patch and minor version upgrades are done automatically without having to change the action. This could be implemented by turning the action into a composite action, where e.g. the node_modules folder is cached for a week on the consumer side. The downside here is that if dependencies fail to follow semver, this can break at the consumer side.

What do you think?

[vyas-n]

Hi @amannn,

I do agree that dependabot can be quite noisy, but having the latest set of dependencies tend to reduce the surface area of problems that can come up over time.

Would you be interested in changing the interval to something like monthly to reduce noise? At least this way you're only sent PRs at the beginning of the month.

Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleinterval

[amannn]

Thanks for chiming in @vyas-n! Monthly sounds better, but grouped updates would be a requirement from my side. Seems like the feature is in public beta now, so maybe we can add this soon!

[chris-bateman]

Grouped updates are now available.
dependabot/dependabot-core#1190 (comment)

[ytausch]

Hi, is there any update on this? For large corporations, these things are sometimes very important.

Thanks for your open-source-work! :)

[amannn]

@ytausch Would you be interested in finishing this PR with grouped updates and a generous interval (ideally 3 months)?

[yeikel]

@ytausch Would you be interested in finishing this PR with grouped updates and a generous interval (ideally 3 months)?

I'd be happy to finish this PR

To confirm, are you looking for a single group or more specialized groups? Any special rule?(ie: minor updates only)

In my experience, grouped updates can become unusable if the group is too ambitious as it often leads to breaking changes or upgrades that are hard to reason about. For example, It is certainly easier to manage one breaking change than manage multiple ones

In that sense, grouped updates need to be strategically crafted, or they'll be useless or hard to manage otherwise

[amannn]

Ah yes, that's a smart suggestion! I guess since this repo doesn't have too many dependencies, we could keep it simple for now and do a single group for everything. If it becomes a hassle, I think I could split it at some point. But I guess it would be reasonable setting to begin with to ensure that everything is up-to-date.

[yeikel]

Ah yes, that's a smart suggestion! I guess since this repo doesn't have too many dependencies, we could keep it simple for now and do a single group for everything. If it becomes a hassle, I think I could split it at some point. But I guess it would be reasonable setting to begin with to ensure that everything is up-to-date.

Understood, thank you!

Just to confirm, one last question:

Are you looking for a single group that spans both ecosystems, or would you prefer two separate groups?

For instance, we can create one group for npm and another for GitHub Actions, or a single group that includes both.

Since they seem unrelated, my recommendation would be to keep them as separate groups(cross-ecosystem groups can be buggy, but that's a different issue), but the choice is yours.

[amannn]

That's a good point, I think one group per ecosystem as you suggest would be a reasonable choice!

[yeikel]

I updated it based on your feedback

• Run quarterly
• Create two dedicated groups: One for NPM and another for GitHub action workflows

You can checkout the demo in my fork

GitHub Actions: yeikel#20
npm: yeikel#21

As a side note, your current build uses version ranges for npm. Now that we have automation in place, we could consider pinning dependencies to specific versions to improve reproducibility and make it easier to troubleshoot.

For example, instead of "@actions/core": "^1.10.0", we could set "@actions/core": "1.10.0", directly.

[amannn]

Looks fantastic, thanks a bunch @yeikel!

we could consider pinning dependencies to specific versions to improve reproducibility and make it easier to troubleshoot.

The yarn.lock file in this repo should take care of pinning the exact versions, I think that should be fine.

However, I'll probably switch to pnpm in a follow-up PR that looks into dependencies, yarn has fallen quite a bit out of fashion.

[github-actions]

🎉 This PR is included in version 6.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[yeikel]

Looks fantastic, thanks a bunch @yeikel!

we could consider pinning dependencies to specific versions to improve reproducibility and make it easier to troubleshoot.

The yarn.lock file in this repo should take care of pinning the exact versions, I think that should be fine.

However, I'll probably switch to pnpm in a follow-up PR that looks into dependencies, yarn has fallen quite a bit out of fashion.

Maybe I am missing something, but my understanding is that running two yarn install in sequence along with version ranges, will lead to install different versions if there are new versions available. Or at least, that's what happens with npm install