I am looking for something similar to GitHub - knl/niv-updater-action: A GitHub Action that creates meaningful pull requests with updates to your niv-managed dependencies, so you don't have to do menial chores.
but for flake.nix to keep the growing number of nix flakes up-to-date.
Has someone already code for this?
3 Likes
Would be great if someone contributed to dependabot to know about flakes.
1 Like
Is this even possible? Maybe using this project: GitHub - dependabot/dependabot-script: A simple script that demonstrates how to use Dependabot Core
It seems like it used to be possible to contribute support for additional languages, but that doesn’t seem to be the case anymore (or I just can’t find it).
According to dependabots contribution guidelines they are not accepting new ecosystems either right now.
1 Like
I have a personal one here, if you’re looking: https://github.com/TLATER/nixos-hosts/blob/e1e9ab7ca211cc6f6958b5275ae131c5dd6ececc/.github/workflows/update.yml
In good ol’ nix user ways a bit overengineered, of course, the signing can probably be ignored if you’re not interested in that 
1 Like
There is also renovate, which does seem to accept new ecosystems as contribution. Would be nice to add Nix flakes and niv.
1 Like
Is it really an good idea to run such an auto updater? I’d very much prefer a flake.lock which was actually used by the maintainer such that I can be sure that the flake will work with that particular lockfile. If I wanted to use an more recent nixpkgs I can always just use —override-input or in the case of modules/overlays the systems nixpkgs version is used anyway.
1 Like
The purpose isn’t to hide it entirely from the maintainer, it just does the tedious bits and lets you review a pull request instead of having to pull out a shell.
It’s a tiny difference, but the fact that it is run regularly and throws notifications at me gets me to actually review and update, rather than letting it lie unmaintained for irregular periods.
Ideally unit tests prevent the scenario you’re considering anyway, and it makes little sense to have this kind of workflow with no testing.
I personally want to combine it with nix-diff in the future, to list exact package version changes in the commit message - this gives more semantic info than traditional flake.lock files can even give
3 Likes