Automerge major dependency updates to reduce traffic

[mcollina]

It’s important that we automerge major updates as they are the only ones that will be opened in most of our repos because we do not use lockfiles.

Let’s trust our tests to detect any potential breakage.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[mcollina]

cc @Fdawgs @Eomm

[Eomm]

I think this change hurt us more than the benefits it takes: mainly the plugins forward some options to external modules.
We had some issues because of that.

Since we are not testing all the external's module options, the CI could be green and merge it.
This means that in some cases we should release the plugin as a major version because the options used by the dev through the fastify's plugin could be changed.

In both cases (with or without the automerge), a fastify maintainer needs to check the external dep's release to decide if it should cause a major or a minor release.

A blocked dependabot's PR is easier to manage than reading the merged PRs and going to check them.

For sure and at least, the dependabot configuration should not call these kinds of PRs as chore.

ref fastify/fastify#3716

[Eomm]

Here are some examples:

• revert dep major bump fastify-websocket#145
• Revert "chore(deps): bump chalk from 4.1.2 to 5.0.0" benchmarks#228
• Revert "chore(deps): bump node-fetch from 2.6.1 to 3.0.0" github-action-merge-dependabot#74

[mcollina]

We have more than 50 modules in this or, mostly they do not have lock files and they only receive dependency updates with a semver-major. Dealing with a few mistakes is significantly less work than manually checking all dependency updates across the full org.

Let's make it this way: I am the one that have historically done most of the releases across the org.

This changes increases the time it takes to release a module as it requires more manual steps and wait for CI runs.

I will have to further reduce the amount of releases I can do (I already have, partially because of this).

Are others willing to pick up the work? I would be happy to let other take the load. I get upset when others increase my workload without giving me more help.

[Eomm]

Dealing with a few mistakes is significantly less work than manually checking all dependency updates across the full org.

Indeed, I think my approach relies less on the final users (that should open an issue) and moves the burden to the maintainer that publishes the release.

Are others willing to pick up the work?

Yes, I'm. I think to have done it a few times already but I can do more for sure.

In any case, I would like to hear some others @fastify/plugins opinions.

[mcollina]

Indeed, I think my approach relies less on the final users (that should open an issue) and moves the burden to the maintainer that publishes the release.

Exactly. My goal is to push as much work as possible on the users. They are not paying for it, doing QA and opening an issue is the minimum they can do.

[Fdawgs]

Sounds good! I agree, users should be testing updates to plugins in their applications/services using CI themselves.
If a dependency breaks a plugin, and it wasn't caught by our own CI, then hopefully users will report this back if it breaks their apps.

[Eomm]

I would propose a parameter instead of removing the target option.

I agree with you at some point, but I would like to define this kind of usage:

• plugin that does not forward configuration to dependencies: target: major
• plugin that does not forward configuration to dependencies AND have a low download rate: target: major
• plugin that forward configuration to dependencies AND have a high download rate target: minor

Adding the parameter would let us apply this setup in both ways reducing the burden.

Notice that this workflow is used by 2 plugins only, I was planning to spread it during the fastify@v4 upgrade

• high download rate = 10k/week

[mcollina]

How about setting the exclude settings of the automerge action? We can just skip the critical dependencies whose options are exposed to the end users.

[Fdawgs]

Notice that this workflow is used by 2 plugins only, I was planning to spread it during the fastify@v4 upgrade

I have been planning on doing it, was just waiting on a general agreement on script naming in #9.

[mcollina]

@Fdawgs do you think we could add a workflow input to pass exclude to the automerge action?

[Fdawgs]

@Fdawgs do you think we could add a workflow input to pass exclude to the automerge action?

Sure! Should have time to add it this evening.