-
Michał Kępień authored
Ensure BIND can be tested on Windows in GitLab to more quickly catch build and test errors on that operating system. Some notes: - While build jobs are triggered for all pipelines, system test jobs are not - due to the time it takes to run the complete system test suite on Windows (about 20 minutes), the latter are only run for pipelines created through GitLab's web interface and for pipelines created for Git tags. - Only the "Release" build configuration is currently used. Adding "Debug" builds is a matter of extending .gitlab-ci.yml, but it was not done for the time being due to questionable usefulness of performing such builds in GitLab CI. - Only a 64-bit build is performed. Adding support for 32-bit builds is not planned to be implemented. - Unit tests are still not run on Windows, but adding support for that is on the roadmap. - All Windows GitLab CI jobs are run inside Windows Server containers, using the Custom executor feature of GitLab Runner as Windows Server 2016 is not supported by GitLab Runner's native Docker on Windows executor and Windows Server 2019 is not yet widely available from hosting providers. - The Windows Docker image used by GitLab CI is not stored in the GitLab Container Registry as it is over 27 GB in size and thus passing it between GitLab and its runners is impractical. - There is no vcvarsall.bat variant written in PowerShell and batch scripts are no longer supported by GitLab Runner Custom executor, so the environment variables set by vcvarsall.bat are injected back into the PowerShell environment by processing the output of "set". - Visual Studio parallel builds are a bit different than "make -jX" builds as parallelization happens in two tiers: project parallelism (controlled by the "/maxCpuCount" msbuild.exe switch) and compiler parallelism (controlled by the "/MP" cl.exe switch). To limit the total number of compiler processes spawned concurrently to a value similar to the one used for Unix builds, msbuild.exe is allowed to build at most 2 projects at once, each of which can spawn up to half of BUILD_PARALLEL_JOBS worth of compiler processes. Using such parameters is a fairly arbitrary decision taken to solve the trade-off between compilation speed and runner load. - Configuring network addresses in Windows Server containers is tricky. Adding 10.53.0.1/24 and similar addresses to the vEthernet interface created by Docker never causes ifconfig.bat to fail, but in fact only one container can have any given IP address configured at any given time (the request to add the same address in another container is silently ignored). Thus, in order to allow multiple system test jobs to be run in parallel, the addresses used in system tests are configured on the loopback interfaces. Interestingly enough, the addresses set on the loopback interfaces... persist between containers. Fortunately, this is acceptable for the time being and only requires ifconfig.bat failures to be ignored (as ifconfig.bat will fail if it attempts to configure an already existing address on an interface). We also need to wait for a brief moment after calling ifconfig.bat as the addresses the latter attempts to configure may not be immediately available after it returns (and that causes runall.sh to error out). Finally, for some reason we also need to signal that the DNS servers on each loopback interface are to be configured using DHCP or else ifconfig.bat will fail to add the requested addresses. - Since named.pid files created by named instances used in system tests contain Windows PIDs instead of Cygwin PIDs and various versions of Cygwin "kill" react differently when passed Windows PIDs without the -W switch, all "kill" invocations in GitLab CI need to use that switch (otherwise they would print error messages which would cause stop.pl to assume the process being killed died prematurely). However, to preserve compatibility with older Cygwin versions used in our other Windows test environments, we alter the relevant scripts "on the fly" rather than in the Git repository. - In the containers used for running system tests, Windows Error Reporting is configured to automatically create crash dumps in C:\CrashDumps. This directory is examined after the test suite is run to ensure no crashes went under stop.pl's radar.
ca36405a
Validating GitLab CI configuration…
Learn more