1. 13 Sep, 2019 3 commits
    • azure: convert to use Ninja as build tool · 48d23a8c
      While we were still supporting Trusty, using Ninja as a build tool would
      have required us to first setup pip and then use it to install Ninja.
      As a result, the speedups from using Ninja were drowned out by the
      time required to install Ninja. But as we have deprecated Trusty now,
      both Xenial and Bionic have recent versions of Ninja in their
      repositories and thus we can now use Ninja.
      Patrick Steinhardt committed
    • azure: deprecate Trusty in favor of Xenial · 76327381
      Support for the LTS release Ubuntu 14.04 Trusty has been dropped in
      April 2019, but Azure is still using Trusty as its primary platform to
      build and test against. Let's deprecate it in favor of Xenial.
      Patrick Steinhardt committed
    • azure: build Docker images as part of the pipeline · 5a6740e7
      The Docker images used for our continuous integration builds currently
      live in the libgit2/libgit2-docker repository. To make any changes in
      them, one has to make a PR there, get it reviewed, re-build the images
      and publish them to Docker Hub. This process is slow and tedious, making
      it harder than necessary to perform any updates to our Docker-based
      build pipeline.
      
      To fix this, we include all Dockerfiles used by Azure from the mentioned
      repository and inline them into our own repo. Instead of having to
      manually push them to the CI, it will now build the required containers
      on each pull request, allowing much greater flexibility.
      Patrick Steinhardt committed
  2. 20 Jul, 2019 7 commits
    • azure: skip SSH tests on Win32 platforms · f867bfa8
      On Win32 build hosts, we do not have an SSH daemon readily available and
      thus cannot perform the SSH tests. Let's skip the tests to not let Azure
      Pipelines fail.
      Patrick Steinhardt committed
    • azure: use bash scripts across all platforms · 0cda5252
      Right now, we maintain semantically equivalent build scripts in
      both Bash and Powershell to support both Windows and non-Windows
      hosts. Azure Pipelines supports Bash on Windows, too, via Git for
      Windows, and as such it's not really required to maintain the
      Powershell scripts at all.
      
      Remove them to reduce our own maintenance burden.
      Patrick Steinhardt committed
    • azure: explicitly specify CMake generator · 8e356f48
      We currently specify the CMake generator as part of the CMAKE_OPTIONS
      variable. This is fine in the current setup, but during the conversion
      to drop PowerShell scripts this will prove problematic for all
      generators that have spaces in their names due to quoting issues.
      
      Convert to use an explicit CMAKE_GENERATOR variable that makes it easier
      to get quoting right.
      Patrick Steinhardt committed
    • azure: replace mingw setup with bash · 443df2df
      We're about to phase out our Powershell scripts as Azure
      Pipelines does in fact support Bash scripts on all platforms. As
      a preparatory step, let's replace our MinGW setup script with a
      Bash script.
      Patrick Steinhardt committed
    • azure: fix building in MinGW via Bash · d8e85d57
      Azure Pipelines supports bash tasks on Windows hosts due to it always
      having Git for Windows included. To support this, the Git for Window
      directory is added to the PATH environment to make the bash shell
      available for execution. Unfortunately, this breaks CMake with the MinGW
      generator, as it has sanity checks to verify that no bash executable is
      in the PATH. So we can either remove Git for Windows from the path, but
      then we're unable to execute bash jobs. Or we can add it to the path,
      but then we're unable to execute CMake with the MinGW generator.
      
      Let's re-model how we set the PATH environment. Instead of setting up
      PATH for the complete build job, we now set a variable "BUILD_PATH" for
      the job. This variable is only being used when executing CMake so that
      it encounters a sanitizied PATH environment without GfW's bash shell.
      Patrick Steinhardt committed
    • azure: move build scripts into "azure-pipelines" directory · ffac520e
      Since we have migrated to Azure Pipelines, we have deprecated and
      subsequentally removed all infrastructure for AppVeyor and
      Travis. Thus it doesn't make a lot of sense to have the split
      between "ci/" and "azure-pipelines/" directories anymoer, as
      "azure-pipelines/" is essentially our only CI.
      
      Move all CI scripts into the "azure-pipelines/" directory to have
      everything centrally located and to remove clutter in the
      top-level directory.
      Patrick Steinhardt committed
    • tests: execute leak checker via CTest directly · d827b11b
      Right now, we have an awful hack in our test CI setup that extracts the
      test command from CTest's output and then prepends the leak checker.
      This is dependent on non-machine-parseable output from CMake and also
      breaks on various ocassions, like for example when we have spaces in the
      current path or when the path contains backslashes. Both conditions may
      easily be triggered on Win32 systems, and in fact they do break our
      Azure Pipelines builds.
      
      Remove the awful hack in favour of a new CMake build option
      "USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind",
      then we will set up all tests to be run under valgrind. Like this, we
      can again simply execute ctest without needing to rely on evil sourcery.
      Patrick Steinhardt committed
  3. 18 Jul, 2019 1 commit
  4. 14 Jun, 2019 1 commit
    • cmake: Modulize our TLS & hash detection · 94fc83b6
      The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
      streamlined. Previously we would have accepted not quite working
      configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
      the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.
      
      The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
      which takes the values "CollisionDetection/Backend/Generic", to better
      match how the "hashing backend" is selected, the default (ON) being
      "CollisionDetection".
      
      Note that, as `SHA1_BACKEND` is still used internally, you might need to
      check what customization you're using it for.
      Etienne Samson committed
  5. 21 May, 2019 1 commit
  6. 14 Feb, 2019 2 commits
  7. 28 Jan, 2019 1 commit
  8. 27 Jan, 2019 1 commit
  9. 26 Jan, 2019 1 commit
  10. 19 Jan, 2019 1 commit
  11. 11 Jan, 2019 1 commit
  12. 26 Oct, 2018 1 commit
  13. 25 Oct, 2018 1 commit
  14. 21 Oct, 2018 4 commits
  15. 18 Sep, 2018 1 commit
  16. 31 Aug, 2018 1 commit
  17. 29 Jul, 2018 1 commit