Earlier quoted context omitted.
I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation. A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again. [1] https…
It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.
Why I recommend Renovate over any other dependency update tools
21–30 of 76 posts
Re: Why I recommend Renovate over any other dependency update tools
#22Earlier quoted context omitted.
I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation. A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again. [1] https…
It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.
Re: Why I recommend Renovate over any other dependency update tools
#23Re: Why I recommend Renovate over any other dependency update tools
#24Earlier quoted context omitted.
I automated renovate PR into its own branch. Then twice a month I automatically create a PR through GitHub actions for me to review all changes at once. I also added a cooldown period that Renovate should only add updates that are out for at least 14 days.
This sounds awesome can you share any details on how you got this to work?
On GitHub I created two actions:
1. It gets triggered on the 14th and the 1st of a month and creates a PR from renovate_updates to dev and assigns it to me. I use an action to identify as a github app that I have given the rights to in the repo. Within the github action you can use gh cli.
2. Everytime there is a merge to the dev branch the action gets trigerred and does a rebase of dev of that "renovate_updates" branch.
The nice thing about this is that Renovate creates an Issue in your repo and you can still force versions if you need them earlier.
Re: Why I recommend Renovate over any other dependency update tools
#25In our projects 80% of renovate updates are broken PR-s. In theory it should save work, but it just generates more.
Re: Why I recommend Renovate over any other dependency update tools
#26I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added. Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen
I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation. A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again. [1] https…
Re: Why I recommend Renovate over any other dependency update tools
#27I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added. Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen
Just like with AWS SaaS offerings: All they need to do is have something basic, satisfying 80% customers, requiring little maintenance on their end.
Re: Why I recommend Renovate over any other dependency update tools
#28In our projects 80% of renovate updates are broken PR-s. In theory it should save work, but it just generates more.
But are they broken because of renovate? Or just the underlying dependency updates?
Re: Why I recommend Renovate over any other dependency update tools
#29Earlier quoted context omitted.
Sounds like you might be understaffed.
It's microservice land! Most of those services are no longer in active development, and nearly all of them support a single actual product. In my opinion, we split them to aggressively at the start - expecting some of them to be used by other people in the company, as a service type of situation - but that never happened. I argued for combining several of them - they don't share any paths for API calls, so it could l…
Make that step 4 or 5.
Mono repo them first! Yes you will have to build some tooling to do this but it gives you a way to test the concept. The moment that you have to change 2 of them with any degree of coordination you will get a 10x pay back.
Re: Why I recommend Renovate over any other dependency update tools
#30Earlier quoted context omitted.
This sounds awesome can you share any details on how you got this to work?
I have a branch lock on dev and main so that you can only merge through PR. So I created a branch from dev called "renovate_updates". In the renovate config I set the baseBranch config parameter to this branch. I also enabled automerge and minimumReleaseAge. On GitHub I created two actions: 1. It gets triggered on the 14th and the 1st of a month and creates a PR from renovate_updates to dev and assigns it to me. I us…