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. Would it make sense to just swap the order, then? 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. Thanks.
