search

Level / community

Discussion, support and common information for projects in the community.
MIT License
42 stars 15 forks source link

Switch to dependabot #89

Closed vweevers closed 3 years ago

vweevers commented 4 years ago

Greenkeeper is shutting down. Anyone opposed to using dependabot instead?

Side note: someone triggered an automated migration of all repo's from Greenkeeper to Snyk.

vweevers commented 4 years ago

Ah. @huan the github audit log shows that you added Snyk?

huan commented 4 years ago

Yes, it caused by my operation with a mistake.

Today I'm trying to migrate my projects from greenkeeper to Snyk, however, the Synk checks all repositories that I have privileges to manage with a not very clear interface, and after I click the next button, it start migrating all of them.

vweevers commented 4 years ago

@huan Alright, that's unfortunate. Thanks for checking in.

In the Snyk interface, can you find an easy way to remove repos or an entire github org? If not, I'll remove all the webhooks manually via GitHub.

huan commented 4 years ago

Sure. I have deleted all the level org repos in the Snyk interface one by one, I hope it has clean all the webhooks.

Please let me know if there's any tasks that need to be done additionally.

vweevers commented 4 years ago

I'm also gonna give Renovate a try, because it seems Dependabot doesn't run tests on in-range dependency updates, like Greenkeeper did.

vweevers commented 4 years ago

Same story with Renovate, sadly. There are three bad options:

  1. Use rangeStrategy: replace. This will open a PR if a new version (e.g. 2.0.0) falls outside the current range (e.g. ^1.0.0). There'll be no tests on in-range updates.
  2. Use rangeStrategy: bump. This will open a PR for any new version. Too noisy. Plus, to allow deduping of dependencies (app-wide) I prefer loose lower bounds on ranges (e.g. ^1.0.0 rather than ^1.6.2 unless that specific version is actually the minimum).
  3. Use lockFileMaintenance. Same effect as (2) but Renovate won't touch package.json. My hatred of lockfiles aside, it's just as noisy as (2). Noise can be reduced by using a schedule, but that misses the goal of getting realtime notifications on breaking in-range updates.

Going with option 1 for now, because it's the least noisy. And greenkeeper's behavior of testing in-range updates did also result in noise, e.g. due to CI failures.

vweevers commented 4 years ago

As for Dependabot vs Renovate, I like the commands you can give to Dependabot on PRs, especially squash and merge which waits for status checks to pass. This means, once you get a notification from GitHub, you don't have to wait and come back to the PR later. Renovate on the other hand is more configurable, and has the great option to only open PRs once status checks pass.

vweevers commented 3 years ago

Dependabot wins. For 3 reasons: the commands, more context on PRs (lists both changelog and commits) and it's faster. Compare https://github.com/Level/level/pull/185 and https://github.com/Level/level-js/pull/199: same dependency, but renovate's PR was delayed by a full month. That said, for the record, dependabot has an unfair advantage and I dislike the vendor lock-in.

vweevers commented 3 years ago

Configured all repo's except for https://github.com/Level/leveljs.org/pull/50.