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)