Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Replace dependabot with renovate #496

Closed
hazendaz opened this issue Feb 15, 2023 · 14 comments
Closed

Replace dependabot with renovate #496

hazendaz opened this issue Feb 15, 2023 · 14 comments
Assignees
@mathieucarbou
Labels
in:build MLP build system (maven) is:feature New feature stale Inactive items that will be automatically closed if not resurrected

Comments

@hazendaz
Copy link
Collaborator

Currently this project uses dependabot. Dependabot has a huge negative impact on contributors that had repos forked long before that which results in excessive downstream pull requests. It also isn't as good at detection. A simple and extremely more effective solution is to use Renovate which is also free.

Steps to introduce.

  • Go to https://github.com/marketplace/renovate
  • Add it for this project
  • Merge the renovate.json PR it raises
  • Pin the issue tracking created afterwards for better tracking of what this project uses
  • Remove the .github/dependabot.xml file
  • Any existing ignores if any are as simple as closing raised new PRs which will update the issue tracking

Example links to see this in action (over at mybatis)

Effort to switch, minutes...
@hazendaz hazendaz added the is:feature New feature label Feb 15, 2023
@hazendaz hazendaz changed the title Replace dependabot with renoate Replace dependabot with renovate Feb 15, 2023
@hazendaz
Copy link
Collaborator Author

to see downstream issues dependabot causes for example hazendaz#107. In past week, if you look at PRs over there on the fork, I've had to close out many from dependabot which is a pain and long, long standing defect with github's dependabot since before they owned it.

@ctubbsii
Copy link
Contributor

For what it's worth, GitHub does allow you to disable dependabot checks on forks... and it's off by default now. So, I don't think this is strictly necessary. See my comment on revelc/formatter-maven-plugin#711 (review)

@mathieucarbou mathieucarbou added the todo Accepted items from the backlog which can be worked on label Mar 23, 2023
@hazendaz
Copy link
Collaborator Author

hazendaz commented Mar 24, 2023 via email

@hazendaz
Copy link
Collaborator Author

hazendaz commented Mar 24, 2023 via email

@ctubbsii
Copy link
Contributor

The link you provided says you can delete/recreate the fork OR click Disable. It's a one-button click. Whether or not the maintainer chooses to go with renovate, I just wanted to make sure that they know it's not strictly necessary to avoid the spam. It's a just a one button click for any existing repos. That button has been there for a long time. The only change is whether it's on by default when you fork.

@hazendaz
Copy link
Collaborator Author

hazendaz commented Mar 24, 2023 via email

@ctubbsii
Copy link
Contributor

It's not on my fork hence the ongoing issue. No button to disable even.

Weird. For your fork, it should be at: https://github.com/hazendaz/license-maven-plugin/settings/security_analysis
The button should be red if enabled. All mine are off.

@hazendaz
Copy link
Collaborator Author

hazendaz commented Mar 24, 2023 via email

@mathieucarbou
Copy link
Owner

I've looked at Renovate and even if I see its value for some other project, for this one, I don't see any advantage over dependabot, besides requiring a more complex config and being less Github-integrated.

I would highly prefer you disable dependabot on your forks (I don't even know how you had that enabled: I have many forks myself and never got any Prs or alerts regarding dependabot on any of my forks...)

Let's keep this issue in the backlog for now.

@mathieucarbou mathieucarbou added in:build MLP build system (maven) and removed todo Accepted items from the backlog which can be worked on labels Mar 24, 2023
@hazendaz
Copy link
Collaborator Author

hazendaz commented Mar 24, 2023 via email

@mathieucarbou
Copy link
Owner

I personnel don't mind changing but I just still does not see the value for this project, even if I completely agree with all what you said :-)
I am not in a company use case... For MLP, one or the other is enough for the needs. Dependency management for MLP is far from being critical and dependabot is more than enough and easier since well integrated inside GitHub's interface.

@hazendaz
Copy link
Collaborator Author

hazendaz commented Apr 2, 2023 •
edited

OK to just reset.

See https://github.com/mathieucarbou/license-maven-plugin/blob/fd7362c9b011d66b29f26a79464372c91b73d466/license-maven-plugin/src/test/resources/check/pom.xml

Dependabot fails to just update all poms. Not to mention it raised a CVE fix we likely just overlooked. Renovate will address these.

In case where everyone is not really cool with external non github solution (dependabot wasn't either at one time), I can just setup my local and let it do the work and merge in. Since this specific project just forces squash, you won't really see that in history unless 1 to 1 merge.

That said, that is the approach I'll take with this and others I'm mostly concerned with. While notes on how to shut up dependabot, none actually work if one came before it was consumed by github (ie greatly affects me but clearly not others). That may have to do with being part of that track originally and separately setup entirely with dependabot in general. As noted, its still reported to github regularly and I keep getting alerts as well when people go after github for poor behavior there. Regardless, keep things as is, going to close this ISSUE, I'll setup what I need, I'll adjust my default branch which also resolves the dependabot madness for me, and I'll raise renovate PRs that way which if you look I merge most of these anyways. That way, no new stuff there, I'm happy, everyone is happy, and we can proceed as usual.

Probably no need to discuss more but a thumbs up or down to my approach will work. I won't bother bringing up the concern again post this as the model I've proposed here is satisfactory to me, think its clearly ok to the group, and we continue on working on real issues, the code :)

@hazendaz hazendaz closed this as completed Apr 2, 2023
@hazendaz hazendaz reopened this May 27, 2023
@hazendaz
Copy link
Collaborator Author

Reopening this as I would like to have this reconsidered once again. Just like my prior note, dependabot is not finding everything. I had to again manually fix some usage. I also have zero clue what dependabot thinks we want, don't want, or what even even use. If setup is a concern, grant me enough access here and within 10 minutes it will be live. It is integrated to github btw. Many in the market place are entirely separate platforms with very little integration this one is not. If team doesn't like it after using it then fine remove it but give it a chance first.

On current dependabot we didn't even setup GHA portion as it has to be told everything, so we miss all those updates.

On renovate dashboard that dependabot does not have, see an example -> hazendaz/base-parent#437

Please reconsider this given in 99% of the cases, I'm the only one merging these as it is. And for my sanity, I prefer to have the defect in dependabot resolved. It still sends PRs constantly to forks. I'd like to be more involved here and this one is super important to me because of the level it actually works. I'm already 100% provisioned with them for long time so setting any repo to it takes roughly 2 minutes. Long enough for it to send me 2FA to approve it and select the repo. In fact, I have the dashboard up now and if I am part of this org, done deal quickly. If anything else, it will at least tell us what our code is made up of.

One thing of note, you still 100% retain integrated dependabot for security vulnerabilities. That part doesn't do away. This is just for the day to day stuff.

@stale
Copy link

stale bot commented Jul 26, 2023

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale Inactive items that will be automatically closed if not resurrected label Jul 26, 2023
@stale stale bot closed this as completed Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mathieucarbou mathieucarbou

Labels
in:build MLP build system (maven) is:feature New feature stale Inactive items that will be automatically closed if not resurrected
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mathieucarbou @hazendaz @ctubbsii