1. 13 Jan, 2020 1 commit
    • Michal Nowak's avatar
      Add openSUSE Tumbleweed image to the CI · 3526c730
      Michal Nowak authored
      Ensure BIND is continuously tested on Tumbleweed, a pure rolling release
      version of openSUSE.  This will allow BIND incompatibilities with latest
      upstream versions of its dependencies to be caught more quickly.
  2. 10 Jan, 2020 1 commit
  3. 09 Jan, 2020 1 commit
  4. 06 Jan, 2020 1 commit
  5. 11 Dec, 2019 7 commits
    • Ondřej Surý's avatar
    • Michal Nowak's avatar
      Update GitLab CI to Fedora 31 · 7aa77038
      Michal Nowak authored
      Since Fedora 31 is the current Fedora release, replace Fedora 30 GitLab
      CI jobs with their up-to-date counterparts.
    • Michał Kępień's avatar
      Add a job creating a release tarball to GitLab CI · 5a4a6b5e
      Michał Kępień authored
      Add a GitLab CI job (which is run only if all other jobs in a pipeline
      succeed) that builds a BIND release tarball, i.e. fetches the source
      tarball from the tarball building job, creates Windows zips, puts
      certain parts of BIND documentation into the appropriate places, and
      packs it all up into a single tarball whose contents can be subsequently
      signed and published.
    • Michał Kępień's avatar
      Add a Windows debug system test job to GitLab CI · 2b1c8c54
      Michał Kępień authored
      Add a system test job for binaries created by Visual Studio in the
      "Debug" build configuration to GitLab CI so that they can be tested
      along their "Release" counterparts when necessary.
    • Michał Kępień's avatar
      Add a Windows debug build job to GitLab CI · 12564928
      Michał Kępień authored
      Add a Visual Studio build job using the "Debug" build configuration to
      GitLab CI without enabling it for every pipeline as it takes about twice
      as long to complete as its "Release" counterpart.
    • Michał Kępień's avatar
      Create and test BIND source tarballs in GitLab CI · 8d567490
      Michał Kępień authored
      Add a set of jobs to GitLab CI that create a BIND source tarball and
      then build and test its contents.  Run those extra jobs only when a tag
      is pushed to the Git repository as they are only meant to be sanity
      checks of BIND source tarball contents.
    • Michał Kępień's avatar
      Include prepare-softhsm2.sh in source tarballs · c0be772e
      Michał Kępień authored
      The util/prepare-softhsm2.sh script is useful for initializing a working
      SoftHSM environment which can be used by unit tests and system tests.
      However, since it is a test-specific script, it does not really belong
      in the util/ subdirectory which is mostly pruned during the BIND source
      tarball creation process.  Move the prepare-softhsm2.sh script to
      bin/tests/ so that its location is more appropriate for its purpose and
      also so that it does not get removed during the BIND source tarball
      creation process, allowing it to be used for setting up test
      environments for tarball-based builds.
  6. 10 Dec, 2019 1 commit
  7. 02 Dec, 2019 1 commit
    • Michał Kępień's avatar
      Do not define ASAN_OPTIONS at build time · 6ee04f84
      Michał Kępień authored
      Disabling ASAN memory leak detection for a build job is pointless
      because ASAN is only used in test jobs.  (Also, memory leak detection
      should not be disabled globally - explicit suppressions should be used
      in case of issues with external code.)
  8. 28 Nov, 2019 1 commit
  9. 20 Nov, 2019 1 commit
  10. 18 Nov, 2019 1 commit
  11. 07 Nov, 2019 2 commits
    • Witold Krecicki's avatar
    • Witold Krecicki's avatar
      netmgr: libuv-based network manager · 70397f9d
      Witold Krecicki authored
      This is a replacement for the existing isc_socket and isc_socketmgr
      implementation. It uses libuv for asynchronous network communication;
      "networker" objects will be distributed across worker threads reading
      incoming packets and sending them for processing.
      UDP listener sockets automatically create an array of "child" sockets
      so each worker can listen separately.
      TCP sockets are shared amongst worker threads.
      A TCPDNS socket is a wrapper around a TCP socket, which handles the
      the two-byte length field at the beginning of DNS messages over TCP.
      (Other wrapper socket types can be implemented in the future to handle
      DNS over TLS, DNS over HTTPS, etc.)
  12. 04 Nov, 2019 1 commit
  13. 25 Oct, 2019 1 commit
    • 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.
  14. 16 Oct, 2019 1 commit
    • 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
  15. 15 Oct, 2019 5 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
    • 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
      As a side note, these changes also attempt to eliminate intermittent,
      bogus GitLab error messages ("There has been a missing dependency
    • 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.
    • 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.
    • Michał Kępień's avatar
      Work around an OpenBSD "make" quirk · 6b5426e1
      Michał Kępień authored
      Consider the following Makefile:
      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.
  16. 09 Oct, 2019 1 commit
  17. 03 Oct, 2019 2 commits
  18. 01 Oct, 2019 2 commits
  19. 26 Sep, 2019 1 commit
    • 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 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.
  20. 17 Sep, 2019 1 commit
    • 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
  21. 12 Sep, 2019 2 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.
    • 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.
  22. 29 Aug, 2019 4 commits
  23. 31 Jul, 2019 1 commit