Hello!
I’m setting up a GitLab CI pipeline for a library, and it looks like OPAM fails to synchronize the source code from the Git repository as part of the opam install . --with-test command.
faker is now pinned to git+file:///builds/Richard-Degenne/ocaml-faker#HEAD (version ~dev)
The following actions will be performed:
[...]
- install faker ~dev*
===== 13 to install =====
<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ERROR] Could not synchronize /home/opam/.opam/5.3/.opam-switch/sources/faker from "git+file:///builds/Richard-Degenne/ocaml-faker#HEAD":
"/usr/bin/git fetch -q" exited with code 128
[...]
[ERROR] The sources of the following couldn't be obtained, aborting:
- faker.~dev
The only two things that catch my eye are:
git fetch exiting with code 128, which is a generic exit code which I need to look into;- The version of the library.
I’m used to see dev as a version for libraries that do not have an explicit version number yet. I’m not sure I understand what faker.~dev is supposed to mean, or if there are any implications that may be relevant to my problem.
The CI job is available here, for anyone curious. 
~dev was the dev before opam 2.2 (#4949). Are you still using opam 2.1? (2.4.0 is the latest version). It shouldn’t matter for your issue though.
This means that git was unable to fetch the repository at /builds/Richard-Degenne/ocaml-faker somehow. Maybe adding -vvv to the command you’re calling to see the result of the git command might help. I would suggest doing that once you’ve updated to 2.4 if possible though (we never know, it might be something that was fixed in the last 5 or so years). If it still fails the same way, try to git clone by hand and see if git has also problems cloning manually.
1 Like
I’m using the ocaml/opam:latest Docker image, which, according to my logs, embeds OPAM 2.0.10.
$ opam --version
2.0.10
Unfortunately, I’m not the one running git fetch here. It’s run by OPAM as part of the opam install . command. Maybe there’s an OPAM settings for flags that should be passed to Git?
I managed to work around the problem by adding --deps-only to the command. That way, I don’t mess around with pinning the current library, and I still get to build and run the tests.
I’d still like to get to the bottom of this thing. 
The -vvv was to pass to opam, not git.
Yes sadly the default opam is 2.0 for backward compatibility purpose but you can use any other versions using the following:
FROM ocaml/opam:<tag>
RUN sudo ln -f /usr/bin/opam-2.4 /usr/bin/opam && opam init --reinit -ni
See ocurrent/docker-base-images#132 for the upstream issue
1 Like
I understand the need for retro-compatibility, but does that mean there is no official OPAM image for 2.1+ at all? :o
As i’ve said, the ocaml/opam images all have 2.1+, you just need to start your dockerfile with: RUN sudo ln -f /usr/bin/opam-<the version you want> /usr/bin/opam && opam init --reinit -ni. This is not ideal but it’s what this image does currently. I have a couple of personal opinions about how this can be improved that i’ve shared in another post (see point 3), but that all depend on the available time of the infrastructure maintainers.
Efforts for an actual official image (as-in docker run ocaml) was started some years ago, but it didn’t go past the working prototype phase due to a lake of available time to gather a proper long-term maintenance team.
But if you’re specifically looking for images shipping the latest opam as /usr/bin/opam i believe ocamlpro/ocaml does it.
1 Like
Got it. Thanks for all the context, it’s much appreciated. I switched to ocamlpro/ocaml for now and adjusted my pipeline accordingly.
I was still encountering a similar issue with opam install so I re-ran it with -vvv as you suggested and here is what came up.
+ /usr/bin/git "symbolic-ref" "--quiet" "--short" "HEAD"
- fatal: detected dubious ownership in repository at '/builds/Richard-Degenne/ocaml-faker'
- To add an exception for this directory, call:
-
- git config --global --add safe.directory /builds/Richard-Degenne/ocaml-faker
Which then pointed me towards this issue on GitLab itself.
The change made in recent Git releases to address CVE-2022-24765 now disallows use of any git commands under the project clone directory if the container runs as a non-root user.
I guess I can see two paths forward:
- Mark the Git repository as safe as part of the CI setup;
- Run the container as root.
How (un)safe is it to run OPAM as root? I know a warning pops up whenever I do, but can there be actual consequences outside of “running stuff as root is usually discouraged”?