On Wed, Jun 03, 2020 at 11:37:08AM +0100, Daniel P. Berrangé wrote: > On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote: > > On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > > > Prior to 2621d48f005a "gnulib: delete all gnulib integration", > > > one could pass ./autogen.sh --no-git to prevent the libvirt build > > > system from running git submodule update. > > > > > > This feature is needed by systems like the Xen Project CI which want > > > to explicitly control the revisions of every tree. These will > > > typically arrange to initialise the submodules check out the right > > > version of everything, and then expect the build system not to mess > > > with it any more. > > > > To be honest I don't understand why would anyone want to keep track of > > all submodules of all projects for any CI and update it manually every > > time the upstream project changes these submodules. Sounds like a lot > > of unnecessary work but maybe I'm missing something. > > Two possible scenarios that I think are valid > > - The CI job script does not have network access > - The CI job script sees the source dir as read-only > > In both cases the CI harness would have to initialize the submodule > before runing the CI job. > > I don't know if this is what Xen CI is hitting, but I think the > request is reasonable none the less. > > Both Jenkins and GitLab CI have option to make the harness init > submodules prior to the job running. My point was that running 'git submodule update --init' will not change anything if all submodules are updated to the correct revision and if the repository was pre-created with submodules and is read-only when the test is executed the git command will not fail as well and everything will be fine. If the submodules are not updated to the correct revision then it will fail and notify the CI users that something is broken. There should not be any need to disable this explicitly unless you want to build libvirt with different revisions of submodules. > > > Despite to the old documentation comments referring only to gnulib, > > > the --no-git feature is required not only because of gnulib but also > > > because of the other submodule, src/keycodemapdb. > > > > > > (And in any case, even if it were no longer required because all the > > > submodules were removed, it ought ideally to have been retained as a > > > no-op for compaibility reasons.) > > > > Well, we will break a lot more by switching to Meson build system where > > everyone building libvirt will have to change their scripts as it will > > not be compatible at all. > > Yes, but I think that's tangential, as the two above reasons will > still apply, and Meson will cope with having submodules pre-initialized. Yes, these are unrelated and I just wanted to point out that compaibility reasons are in most cases not valid to changes to build system or moving files around in git repository and so on. Pavel
Attachment:
signature.asc
Description: PGP signature
