Junio C Hamano <gitster@xxxxxxxxx> writes: > Karthik Nayak <karthik.188@xxxxxxxxx> writes: > >> Step #1, clones the repository, since the `git` executable isn't present >> at this step, it uses GitHub's REST API to obtain a tar of the >> repository. >> >> Step #2, installs all dependencies, which includes the `git` executable. >> >> Step #3, sets up the build, which includes setting up meson in the meson >> job. At this point the `git` executable is present, so within meson >> `git.found()` would be true. As such we run 'git ls-files' as part of my >> patch series, but since the repository doesn't contain the `.git` >> folder, the command fails. >> >> So like Phillip mentioned, we need to ensure that the `git` executable >> is present before step #1. >> >> I hope that makes sense. > > Please roll that into the appropriate commit log message for the fix > you'd send out, so the next person who wonders why this topic broke > the CI does not have to ask the same question. > Yeah, will do! > Would it make sense to just swap the order, then? Unfortunately not, this is a chicken-egg problem. The dependencies are installed by 'ci/install-dependencies.sh', which are not present until the source is available. > Our sources are > meant to be buildable from either release tarballs (which is created > by "make dist") or a repository (with .git), but from the analysis > of Phillip and you, it sounds like the CI environment has been > building and testing from a "git archive HEAD" output extracted as a > tarball, which is *not* something any real users build from. Making > sure that building from release tarballs works is a good thing to > ensure in CI, because all our developers are testing in their own > repository (with .git) so we wouldn't easily notice ourselves if we > broke the build procedure in such a way that it would somehow > require say "git describe" or "git ls-files" to work. > Another additional point is that this also means that the two CIs (GitLab and GitHub) now run builds differently, while it would be nice to have a separate job to test building on tarballs. I would say currently we should fix this to build on a Git repository. > Thanks.
Attachment:
signature.asc
Description: PGP signature
