1. 04 Nov, 2019 40 commits
  2. 25 Oct, 2019 40 commits
    • Michał Kępień's avatar
      Add CentOS 8 to GitLab CI · dce1c050
      Michał Kępień authored
      Ensure BIND can be tested on CentOS 8 in GitLab CI to more quickly catch
      build and test errors on that operating system.
      dce1c050
  3. 16 Oct, 2019 40 commits
    • Michał Kępień's avatar
      Fix cppcheck 1.89 warnings · abfde3d5
      Michał Kępień authored
      cppcheck 1.89 enabled certain value flow analysis mechanisms [1] which
      trigger null pointer dereference false positives in lib/dns/rpz.c:
      
          lib/dns/rpz.c:582:7: warning: Possible null pointer dereference: tgt_ip [nullPointer]
            if (KEY_IS_IPV4(tgt_prefix, tgt_ip)) {
                ^
          lib/dns/rpz.c:1419:44: note: Calling function 'adj_trigger_cnt', 4th argument 'NULL' value is 0
            adj_trigger_cnt(rpzs, rpz_num, rpz_type, NULL, 0, true);
                                                     ^
          lib/dns/rpz.c:582:7: note: Null pointer dereference
            if (KEY_IS_IPV4(tgt_prefix, tgt_ip)) {
                ^
          lib/dns/rpz.c:596:7: warning: Possible null pointer dereference: tgt_ip [nullPointer]
            if (KEY_IS_IPV4(tgt_prefix, tgt_ip)) {
                ^
          lib/dns/rpz.c:1419:44: note: Calling function 'adj_trigger_cnt', 4th argument 'NULL' value is 0
            adj_trigger_cnt(rpzs, rpz_num, rpz_type, NULL, 0, true);
                                                     ^
          lib/dns/rpz.c:596:7: note: Null pointer dereference
            if (KEY_IS_IPV4(tgt_prefix, tgt_ip)) {
                ^
          lib/dns/rpz.c:610:7: warning: Possible null pointer dereference: tgt_ip [nullPointer]
            if (KEY_IS_IPV4(tgt_prefix, tgt_ip)) {
                ^
          lib/dns/rpz.c:1419:44: note: Calling function 'adj_trigger_cnt', 4th argument 'NULL' value is 0
            adj_trigger_cnt(rpzs, rpz_num, rpz_type, NULL, 0, true);
                                                     ^
          lib/dns/rpz.c:610:7: note: Null pointer dereference
            if (KEY_IS_IPV4(tgt_prefix, tgt_ip)) {
                ^
      
      It seems that cppcheck no longer treats at least some REQUIRE()
      assertion failures as fatal, so add extra assertion macro definitions to
      lib/isc/include/isc/util.h that are only used when the CPPCHECK
      preprocessor macro is defined; these definitions make cppcheck 1.89
      behave as expected.
      
      There is an important requirement for these custom definitions to work:
      cppcheck must properly treat abort() as a function which does not
      return.  In order for that to happen, the __GNUC__ macro must be set to
      a high enough number (because system include directories are used and
      system headers compile attributes away if __GNUC__ is not high enough).
      __GNUC__ is thus set to the major version number of the GCC compiler
      used, which is what that latter does itself during compilation.
      
      [1] https://github.com/danmar/cppcheck/commit/aaeec462e6d96bb70c2b1cf030979d09e2d7c959
      abfde3d5
  4. 15 Oct, 2019 40 commits
    • Michał Kępień's avatar
      Limit triggers for OpenBSD system test jobs · 603e0456
      Michał Kępień authored
      When a GitLab CI runner is not under load, a single OpenBSD system test
      job completes in about 12 minutes, which is considered decent.  However,
      such jobs are usually multiplexed with other system test jobs on the
      same host, which causes each of them to take even 40 minutes to
      complete.  Taking retries into account, this is completely unacceptable
      for everyday use, so only start OpenBSD system test jobs for pipelines
      created through GitLab's web interface and for pipelines created for Git
      tags.
      603e0456
    • Michał Kępień's avatar
      Tweak dependencies for the Windows build job · dd97dfdc
      Michał Kępień authored
      Since the Windows build job does not use the files created as a result
      of running "autoreconf -fi" in the "autoreconf:sid:amd64" job, set its
      dependencies to an empty list.
      
      Since it is currently not possible to use "needs: []" for jobs which do
      not belong to the first stage of a pipeline, set the "needs" key for the
      Windows build job to the "autoreconf:sid:amd64" job so that all build
      jobs are started at the same time (without this change, the Windows
      build job does not start until all jobs in the "precheck" stage are
      finished).
      
      As a side note, these changes also attempt to eliminate intermittent,
      bogus GitLab error messages ("There has been a missing dependency
      failure").
      dd97dfdc
    • Michał Kępień's avatar
      Fix artifacts created by the "autoreconf" CI job · e83b322f
      Michał Kępień authored
      The intended purpose of the "autoreconf:sid:amd64" GitLab CI job is to
      run "autoreconf -fi" and then pass the updated files on to subsequent
      non-Windows build jobs.  However, the artifacts currently created by
      that job only include files which are not tracked by Git.  Since we
      currently do track e.g. "configure" with Git, the aforementioned job is
      essentially a no-op.  Fix by manually specifying the files generated by
      the "autoreconf:sid:amd64" job that should be passed on to subsequent
      build jobs.
      e83b322f
    • Michał Kępień's avatar
      Add OpenBSD to GitLab CI · 07d2fcb5
      Michał Kępień authored
      Ensure BIND can be tested on OpenBSD in GitLab CI to more quickly catch
      build and test errors on that operating system.
      
      Some notes:
      
        - While GCC is packaged for OpenBSD, only old versions (4.2.1, 4.9.4)
          are readily available and none of them is the default system
          compiler, so we are only doing Clang builds in GitLab CI.
      
        - Unit tests are currently not run on OpenBSD because it ships with an
          old version of kyua which does not handle skipped tests properly.
          These jobs will be added when we move away from using kyua in the
          future as the test code itself works fine.
      
        - All OpenBSD jobs are run inside QEMU virtual machines, using GitLab
          Runner Custom executor.
      07d2fcb5
    • Michał Kępień's avatar
      Work around an OpenBSD "make" quirk · 6b5426e1
      Michał Kępień authored
      Consider the following Makefile:
      
          foo:
          	false
      
      On OpenBSD, the following happens for this Makefile:
      
        - "make foo" returns 1,
        - "make -k foo" returns 0,
        - "make -k -j6 foo" returns 1.
      
      However, if the .NOTPARALLEL pseudo-target is added to this Makefile,
      "make -k -j6 foo" will return 0 as well.
      
      Since bin/tests/Makefile contains the .NOTPARALLEL pseudo-target,
      running "make -k -j6 test" from bin/tests/ on OpenBSD prevents any
      errors from being reported through that command's exit code.
      
      Work around the issue by running "make -k -j6 test" in the
      bin/tests/system/ directory instead as bin/tests/system/Makefile does
      not contain the .NOTPARALLEL pseudo-target and thus things work as
      expected there.
      6b5426e1
  5. 09 Oct, 2019 40 commits
  6. 03 Oct, 2019 40 commits
  7. 01 Oct, 2019 40 commits
  8. 26 Sep, 2019 40 commits
    • Michał Kępień's avatar
      Add Windows to GitLab CI · ca36405a
      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
  9. 17 Sep, 2019 40 commits
    • Michał Kępień's avatar
      Run FreeBSD jobs automatically for all pipelines · f7bc9540
      Michał Kępień authored
      No problems have been observed on the FreeBSD GitLab CI runner during
      the burn-in period, when FreeBSD jobs needed to be triggered manually.
      Thus, make the FreeBSD jobs run automatically along other GitLab CI
      jobs.
      f7bc9540
  10. 12 Sep, 2019 40 commits
    • Michał Kępień's avatar
      Add FreeBSD to GitLab CI · 51af91d0
      Michał Kępień authored
      Ensure BIND can be tested on FreeBSD in GitLab to more quickly catch
      build and test errors on that operating system.  Make the relevant jobs
      optional until the CI environment supporting them is deemed stable
      enough for continuous use.
      
      FreeBSD jobs are run using the Custom executor feature of GitLab Runner.
      Unlike the Docker executor, the Custom executor does not support the
      "image" option and thus some way of informing the runner about the OS
      version to use for a given job is necessary.  Arguably the simplest way
      of doing that without a lot of code duplication in .gitlab-ci.yml would
      be to use a YAML template with a "variables" block specifying the
      desired FreeBSD release to use, but including such a template in a job
      definition would cause issues in case other variables also needed to be
      set for that job (e.g. CFLAGS or EXTRA_CONFIGURE for build jobs).  Thus,
      only one FreeBSD YAML template is defined instead and the Custom
      executor scripts on FreeBSD runners extract the OS version to use from
      the CI job name.  This allows .gitlab-ci.yml variables to be defined for
      FreeBSD jobs in the same way as for Docker-based jobs.
      51af91d0
    • Michał Kępień's avatar
      Set --logfile for all kyua invocations · 1bffa602
      Michał Kępień authored
      When kyua is called without the --logfile command line option, the log
      file is created at a default location which is derived from the HOME
      environment variable.  On FreeBSD GitLab CI runners, /home is a
      read-only directory and thus kyua invocations not using the --logfile
      option fail when HOME is set to something beneath /home.  Set --logfile
      to /dev/null for all kyua invocations whose logs are irrelevant in order
      to prevent kyua failures caused by HOME being non-writable.
      1bffa602
  11. 29 Aug, 2019 40 commits
  12. 31 Jul, 2019 40 commits
  13. 30 Jul, 2019 40 commits
    • Michał Kępień's avatar
      Add Alpine Linux to GitLab CI · 326a334b
      Michał Kępień authored
      Ensure BIND is continuously tested on Alpine Linux as it is commonly
      used as a base for Docker containers and employs a less popular libc
      implementation, musl libc.
      326a334b
  14. 23 Jul, 2019 40 commits
    • Ondřej Surý's avatar
      Revert to patch generating check-cocci script · 7f828a21
      Ondřej Surý authored
      The coccinelle and util/update_copyright script have different
      idea about how the whitespace should look like.  Revert the script
      to the previous version, so it doesn't mangle the files in place,
      and deal with just whitespace changes.
      7f828a21
  15. 22 Jul, 2019 40 commits
    • Michał Kępień's avatar
      Add dnstap builds to CI · 2bf44c6c
      Michał Kępień authored
      Ensure BIND with dnstap support enabled is being continuously tested by
      adding --enable-dnstap to the ./configure invocation used for CentOS 7
      and Debian sid builds in GitLab CI.
      2bf44c6c
    • Michał Kępień's avatar
      Add Debian buster to CI · 5f71d9c6
      Michał Kępień authored
      Ensure BIND is continuously tested on Debian 10 (buster) as it is the
      current stable Debian release.
      5f71d9c6
  16. 12 Jul, 2019 40 commits
  17. 09 Jul, 2019 40 commits
  18. 08 Jul, 2019 40 commits
  19. 04 Jul, 2019 40 commits
  20. 03 Jul, 2019 40 commits
  21. 02 Jul, 2019 40 commits
  22. 25 Jun, 2019 40 commits
  23. 21 Jun, 2019 40 commits
  24. 11 Jun, 2019 40 commits