[Chore] Make it possible to override input instead of updating

[rvem]

Problem: We'd like to have an ability to massively apply flake inputs overrides in our repos in order to test some updates before merging potentially breaking changes.

Solution: Make it possible to specify an attrset of input name and override url in the list of inputs to update. For each such entry in the inputs list, 'flake.lock' update will be done using '--override-input' instead of '--update-input'.

Config usage example for the overriding:

...
    "inputs": [
        {
            "input": "nixpkgs",
            "override_url": "github:nixos/nixpkgs"
        }
    ],
    "repos": [
      {
        "owner": "serokell",
        "repo": "update-daemon",
        "settings": {},
        "type": "github"
      }
    ],
...

Related YT issue: https://issues.serokell.io/issue/OPS-1478

[lierdakil]

I vaguely get the overall idea, but I'm very fuzzy on the details of how this would work, mostly because I don't know how/where update-daemon is actually run. Is the intention to basically change the config before doing an update proper and seeing how that pans out in auto-update PRs? Is there a qualitative difference from actually doing the update in the first place and seeing how things shake out (aside from which repo the commits switching out versions end up in)?

[rvem]

Is the intention to basically change the config before doing an update proper and seeing how that pans out in auto-update PRs?

Yes, more-or-less, but my idea was to create separate PRs for this, e.g. see https://github.com/serokell/aquarius-infra/pull/169

Is there a qualitative difference from actually doing the update in the first place and seeing how things shake out

Just to attempt to catch issues from the "upstream" (e.g. sometimes nixpkgs might be broken) and postpone the update or patch our fork if needed

[rvem]

but I'm very fuzzy on the details of how this would work, mostly because I don't know how/where update-daemon is actually run

Currently update-daemon is invoked on a daily basis on our build server.
However, my idea was to invoke it separately (either manually or from the CI) to create PRs that will test the update.

[lierdakil]

Okay, so I've looked over the related slack thread, and I think I have a better grasp of the intent. As an "advance warning system" this makes sense. So correct me if I'm wrong, you're essentially planning to do something like nix flake lock --override-input nixpkgs github:NixOS/nixpkgs every so often in a branch separate from the automatic-update one? In that case, I would suggest manually running it isn't really justified, you could just as well run it automatically. Anyway, IIUC, the changes in this here PR are fit for this purpose (although some additional setup is required on the infra side, but nothing too bad), so I'll approve this.

That being said, do you suppose adding --refresh to the arguments while at it would make sense? I'm a little fuzzy on when exactly nix decides flake repos need redownloading, so maybe it's superfluous if you'll be running it rarely enough. OTOH, it shouldn't really hurt anything either, and could be helpful if you re-trigger manually within a short timespan.