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.

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

Already on GitHub? Sign in to your account

馃挕 How to silently update lock files? #3

Closed
gr2m opened this issue Apr 26, 2021 · 1 comment
Closed

馃挕 How to silently update lock files? #3

gr2m opened this issue Apr 26, 2021 · 1 comment
Labels
idea an idea for a live show

Comments

@gr2m
Copy link
Owner

gr2m commented Apr 26, 2021

I started using @renovateapp for dependency management in most of my open source projects. Greenkeeper is discontinued (RIP), Dependabot is geared towards apps, not libraries, and I'm not aware of any other good alternative for JavaScript projects.

I liked the way Greenkeeper did in-range dependency update checks. It created a branch for the dependency's in-range update, it ran the CI, if there was no error, the branch was deleted. As a maintainer, I didn't get a single notification in the whole process. If the CI failed, Greenkeeper would create an issue to make me aware of the problem. It would also automatically close that issue if the next version update no longer failed.

Renovate does not offer that option, because it requires to keep state for repositories which Renovate doesn't have. At least that's the explanation I got the last time I asked (correct me if I'm wrong @rarkins). Renovate offers the option to do lock file updates, but it cannot merge the changes into the default branch if it is protected, which results in a huge amount notifications across all the repositories, currently it's 100+ each Sunday late afternoon for me.

image

As an alternative, I'd like to build a GitHub action which can push changes to a protected default branch. It could run on a schedule, checkout the repository, update all dependencies, commit the changes to package-lock.json. Then it would run the tests. If they all succeeded, the change would be pushed to the default branch. If they failed, the changes would be pushed to a branch and a pull request would opened for investigations.

The action could run quite frequently and push changes to the main branch if there are no open pull requests. And with a less frequent interval it would force an update, even if there are open pull requests, to make sure the main repository is up to date. Another trigger could be when a pull request is merged or closed.

@gr2m gr2m added the idea an idea for a live show label Apr 26, 2021
@gr2m
Copy link
Owner Author

gr2m commented May 31, 2021

closing in favor of #22

@gr2m gr2m closed this as completed May 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea an idea for a live show
Projects
None yet
Development

No branches or pull requests

1 participant