What's up with
Now run 'opam upgrade' to apply any package updates. + (script @ line 12) $ opam install --confirm-level=unsafe-yes -j 2 . --deps-only Error: Command "/usr/bin/git ls-files" failed: "/usr/bin/git ls-files" exited with code 128
Seems to be happening systematically...
I thought it would be fixed by your CI changes, apparently not
I debugged for about an hour this morning - no idea what's going on
I didn't find the problem reported on the Internet
I can't reproduce locally
MetaCoq doesn't use git ls-files
The Coq action also does not mention ls-files anywhere in its repo
So I think it's really coming from within opam
It's used in the
pin command (opamPinned.ml
) via opams_of_dir_w_target
Where there is a call
git repo_root ~verbose:false [ "ls-files" ] @@> fun r ->
But given that we can't reproduce locally, this info doesn't help that much
Other Coq docker action based projects do not seem to have the issue
Hmm, the mistery thickens
I can find info online that applies to actions that want to commit to the repo: https://jonathansoma.com/everything/git/github-actions-403-error/
But that's not what we're doing
Ah, I also tried running the command
git ls-files as part of the
checktodos action - that also works fine
So it's not just about any run of
opam is using a specific one that fails...
Probably that's it
I saw that, but we don't have the
fatal: ls-files -i must be used with either -o or -c part in the output
For us it's just
/usr/bin/git ls-files failed
No additional args, especially not
There's one other call of
git ls-files in
(git dir ["ls-files"; "--others"; "--exclude-standard"]
It was removed from opam two weeks ago: https://github.com/ocaml/opam/commit/7ebd76871e62334651009e6a8faadae9fbb80711
The one in opamGit.mll
That seems to be in
That could be a hint
But the commit message " git: differentiate non initialised repo and branch not found errors " does not really apply to our situation
This might be related too..
Any ideas why it happens just now?
I have no idea :)
I tried using the checkout@v3 action, it might also be it
sudo chown -R coq:coq breaks something? Because then the
.git repo has the wrong owner?
Ah no, that can't be it, because we're not even getting far enough for this to be run
I think that was it
Indeed we need to run
sudo chown -R coq:coq . before anything is executed. And a bit confusingly, even though it is defined later in our workflow file,
before_script (where the
chown happened) is executed after
before_install (where it has to happen and happens now)
Why this only seems to affect MetaCoq, I have no idea...
Wow, well done!
I was about to give up again as Cléo has woken up :)
I'm guessing that the version of
git used by Coq's docker image(s) was recently updated? fiat-crypto's docker CI also started failing recently with issues related to https://github.com/actions/checkout/issues/766, see https://github.com/mit-plv/fiat-crypto/pull/1578
(To add more detail: it used to be the case that you only needed the
chown commands to get write access to the files. However, since around April 2022, the newer versions of git also fail on read-only commands (like
ls-files) if the directory is owned by the wrong user. If the docker images only recently bumped their git versions, this would explain the issue.)
Hi @Jason Gross,
I think your latest explanation makes sense, indeed.
Does this mean that @Michael Soegtrop's suggestion in https://github.com/coq-community/docker-coq-action/issues/70 should not be applied to https://github.com/coq-community/docker-coq-action#permissions ?
Anyway, I won't have much time this week, so please feel free to open a PR in docker-coq-action (if you believe you did enough tests regarding the "necessary conditions" for the workaround to be applied :+1:)
Yeah, I think https://github.com/coq-community/docker-coq-action/issues/70 is no longer sufficient given the new version of git, while sudo chown is still sufficient I believe
I opened an issue in https://github.com/coq-community/docker-coq-action/issues/86; stay tuned for the upcoming fix.
Last updated: Jun 03 2023 at 17:29 UTC