Releases once per-day

[boesing]

Hey there,

first of all: thanks for this action. This safes me a whole bunch of manually merging PRs from dependabot.

What do you want to achieve?

I actually have this action as part of my repository. It does update deps on a weekly base and this action always have a huge amount of releases in between.

There were 3 releases on thursday last week within 4 Minutes:
https://github.com/ridedott/merge-me-action/releases/tag/v2.8.41
https://github.com/ridedott/merge-me-action/releases/tag/v2.8.42
https://github.com/ridedott/merge-me-action/releases/tag/v2.8.43

So whenever whatever chore dependency is merged to this repository, a new release is being tagged. I don't think that this is really necessary and creates a whole bunch of versions which almost no one will ever use (due to the constraints used in upstream projects).

The worst thing what might happen is, that some of your dependencies starts using the same logic as this component uses: Whenever a dependency has changes, bump that dependency via dependabot and create a release.

This will end-up in an infinite loop and depending on the frequency dependabot will create PRs to bump dependencies, this wont end-up well 😅

What is the current way of working?

Every dependabot PR which is being merged will end-up being a dedicated release. 🤷🏼‍♂️

How much does it hurt?

Not that much. Just realized this in my package and having that large amount of releases might not be necessary.

[acazacu]

Hi @boesing, we are working on limiting the release cycle to only trigger with dependency updates, and not devDependencies. That might reduce the influx of releases, somewhat.

[boesing]

Hey @acazacu, that would be awesome as well!
Didn't wanted to be too strict here but yah, that would be the most preferred way tho.
Thanks for the feedback, this is very appreciated!

[Ocramius]

I'm also kinda affected by this: getting a dozen bumps (or more) a day from this action constantly moving. Good for regular builds, bad for noise and environmental impact...

The offending action seems to be ridedott/release-me-action being triggered on every master push:

merge-me-action/.github/workflows/continuous-delivery.yaml

Lines 38 to 46 in b113d0a

	- env:
	GITHUB_TOKEN: ${{ secrets.DOTTBOTT_TOKEN }}
	id: release
	name: Release
	uses: ridedott/release-me-action@v3.6.3
	with:
	commit-assets: |
	./dist
	node-module: true

I'm wondering if a git diff <latest-tag>..HEAD src package.json could help there: would certainly need some semantic diffing for package.json 🤔

[Ocramius]

Any way I can help with this? What would be the right approach to implementing this?

Practically, this has been causing almost daily PRs for dozens of repositories for the last year.

An example of a repo where I introduced this recently: https://github.com/Roave/DocbookTool/pulls?q=is%3Apr+is%3Aclosed+merge-me-action

[aaneitchik]

Hi @Ocramius, thank you for the example (that is not nice indeed) and for highlighting this issue again!

I merged today the PR that will skip the release of merge-me-action for dev dependency updates (all credits to whoever implemented that possibility in https://github.com/ridedott/release-me-action, I just used it). Seeing as there was no release for the last dependabot PR, looks like it worked 🙂 As of today, merge-me-action should release only when dependencies (not dev ones) are updated or actual changes are made. Hope this helps!

[Ocramius]

Awesome! Thanks @aaneitchik, this really helps a lot 🙏

I guess we wait and observe for a few days 😁

[boesing]

After waiting a few days, I can say that the release amount have been reduced a bit.
Since this action consumes ridedott/release-me-action which still creates releases for dev-only dependency changes, there are still some dependabot PRs regarding this action.

This release for example only had deps-dev changes:
https://github.com/ridedott/release-me-action/releases/tag/v3.6.40

If these releases could be reduced as well, I would be 100% happy with it.

Thanks for your work, @aaneitchik!