This changes how we think about this directory; it does not need to be
exclusively for scripts related to updates, but should be a place for
any scripts intended to be run by CI workflows.
This mindset should make it easier to develop and test the business
logic of workflows, without always needing to test "in production" on
the nixvim repo or a fork.
Rename `inputs.nixpkgs` to `inputs.dev-nixpkgs` to avoid shadowing the
root flake's `inputs.nixpkgs`.
Having the dev flake shadow an input can be confusing, since overriding
the root flake's input will have no effect when evaluating outputs that
depend on the dev partition.
The only reason we specify a `nixpkgs` input at all here, is so the
other inputs can follow it.
Once nix 2.26 is more prevalent, we can follow the root flake's inputs
using a `"path:../.."` input.
Need to use raw output to avoid having a quoted string, otherwise we end
up with a malformed flakeref:
error: in URL 'github:NixOS/nixpkgs/"2d068ae5c6516b2d04562de50a58c682540de9bf"',
'"2d068ae5c6516b2d04562de50a58c682540de9bf"' is not a commit hash or branch/tag name
This removes the need for end-users to manually set
`nixvim.inputs.devshell.follows = ""` (etc)
We offload evaluation of some of our flake modules into a `dev`
partition submodule.
- When its not needed, this submodule is not evaluated.
- When it is needed, it fetches extra inputs from `flake/dev/flake.nix`
as part of evaluating the submodule.
See https://flake.parts/options/flake-parts-partitions.html
Most of the time we want to re-apply "manual"/"additional" commits from
the already open PR, however it is possible we may wish to run the CI
without doing so.
Add an on-by-default tickbox to toggle the `re_apply` step.
Instead of comparing the nixpkgs input revision, we can re-apply any
manually committed changes and then check if any files are different
before pushing.
Cancelling via `exit 1` will mark the workflow as "failed". Instead we
can write a `cancelled` step output and have all the following steps
be conditional.
This should help mitigate spammy force-pushes that don't actually update
the nixpkgs input.
This only affects _scheduled_ runs. Manually triggered updates will
always force-push to the update branch.
Split scheduling other branches into a dedicated workflow. The main
update workflow is no longer responsible for triggering the workflow on
_other_ branches.
- Run the `update.yml` workflow on the triggered branch, replace the
job matrix with a conditional step that runs update on nixos-24.05.
- Added a `cancel-in-progress` concurrency group.
- Disabled committing in PR action (using negative add-paths).
- Rename workflow to simply "update"
- Drop the DeterminateSystems/update-flake-lock action
- Instead use `nix flake update --commit-lock-file`
- Also use `generate-files`'s `--commit` option
- Use peter-evans/create-pull-request to open a PR
