Update nix lock file and check in CI that nix lock file is in sync with nix flake#4838
Merged
automergerpr-permission-manager[bot] merged 2 commits intodevelopfrom Jul 3, 2025
Merged
Conversation
rv-jenkins
requested review from
F-WRunTime,
ehildenb,
rv-jenkins and
tothtamas28
as code owners
juliankuners
force-pushed
the
nix-lockfile
branch
from
f1911eb to
1495770
Compare
Contributor
Author
|
@tothtamas28 Could you please review and merge this? Installing k with kup is currently broken without this PR. |
tothtamas28
approved these changes
Jul 3, 2025
automergerpr-permission-manager
Bot
merged commit fa59c0c
into
develop
20 of 21 checks passed
Merged
automergerpr-permission-manager Bot
pushed a commit
that referenced
this pull request
Jul 16, 2025
In PR #4838, the nix lock file `flake.lock` was updated to be in sync again with `flake.nix`, which is a hard-requirement for `kup` and `nix` to be able to install `k` properly. This PR also added a check in CI that makes sure that the lock file is actually in sync with the flake file. In PR #4834, the develop branch was merged with the PR branch, which causes the new check to be included in the PR branch. In addition, the `update deps` workflow of the respective update PR was automatically run that updated nix lock file. For some reason, the `flake.lock: update` commit [generated a wrong lock file](76f0afe#diff-216b2b7bfde9416c79d133bacb031e95702a20bdedb548c0b055c837aa4f6a9cL169) that is un-sync with the `flake.nix` file in the same commit. Normally, this should have been detected by the new check in the test PR workflow, but it was not. The [first CI test run succeeded](https://github.com/runtimeverification/k/actions/runs/16276235659/attempts/1) and the PR was merged afterwards. I restarted a CI run on this PR, [which failed as expected](https://github.com/runtimeverification/k/actions/runs/16276235659/job/46028193744#step:7:20). In my opinion, this should not actually happen and could have been caused by a checkout of the wrong commit in CI? But on a second thought, I observed that the [test CI workflow succeeded for MacOS](https://github.com/runtimeverification/k/actions/runs/16276235659/job/46028193732#step:6:16) due to the store paths being already in the nix store, which means that the nix flake was actually build already build by CI as is, without changes. So in conclusion, this is either sum bug in the checkout of repositories (unlikely I guess) or some very weird bug by nix (more likely). Therefore, we should update the versions of nix used in the MacOS CI and the workflows of this repository, as both use rather old versions of nix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Recently, the nix flake was updated in a pull request without fully updating the respective nix lock file. This causes issues when trying to install a nix derivation from CLI, i.e. with
nixorkup, without cloning the repository, as the checked out source is placed in the read-only nix store. Therefore, the nix lock file must always stay perfectly in sync with the nix flake.This pull request updates the nix lock file to be in sync again. Additionally, the flag
--no-update-lock-filewas added to CI when building the nix derivation to check that the nix lock file is actually in sync. Otherwise, CI would silently update the nix lockfile without reflecting that change in a commit. This additional sanity check could also be added to other RV repositories with CI that use nix.