1. 13 Mar, 2020 1 commit
  2. 11 Feb, 2020 1 commit
    • cmake: consolidate Valgrind option · 877054f3
      OpenSSL doesn't initialize bytes on purpose in order to generate
      additional entropy. Valgrind isn't too happy about that though, causing
      it to generate warninings about various issues regarding use of
      uninitialized bytes.
      
      We traditionally had some infrastructure to silence these errors in our
      OpenSSL stream implementation, where we invoke the Valgrind macro
      `VALGRIND_MAKE_MEMDEFINED` in various callbacks that we provide to
      OpenSSL. Naturally, we only include these instructions if a preprocessor
      define "VALGRIND" is set, and that in turn is only set if passing
      "-DVALGRIND" to CMake. We do that in our usual Azure pipelines, but we
      in fact forgot to do this in our nightly build. As a result, we get a
      slew of warnings for these nightly builds, but not for our normal
      builds.
      
      To fix this, we could just add "-DVALGRIND" to our nightly builds. But
      starting with commit d827b11b (tests: execute leak checker via CTest
      directly, 2019-06-28), we do have a secondary variable that directs
      whether we want to use memory sanitizers for our builds. As such, every
      user wishing to use Valgrind for our tests needs to pass both options
      "VALGRIND" and "USE_LEAK_CHECKER", which is cumbersome and error prone,
      as can be seen by our own builds.
      
      Instead, let's consolidate this into a single option, removing the old
      "-DVALGRIND" one. Instead, let's just add the preprocessor directive if
      USE_LEAK_CHECKER equals "valgrind" and remove "-DVALGRIND" from our own
      pipelines.
      Patrick Steinhardt committed
  3. 31 Jan, 2020 1 commit
    • azure-pipelines: properly expand negotiate passwords · 7aa99dd3
      To allow testing against a Kerberos instance, we have added variables
      for the Kerberos password to allow authentication against LIBGIT2.ORG in
      commit e5fb5fe5 (ci: perform SPNEGO tests, 2019-10-20). To set up the
      password, we assign
      
          "GITTEST_NEGOTIATE_PASSWORD=$(GITTEST_NEGOTIATE_PASSWORD)"
      
      in the environmentVariables section which is then passed through to a
      template. As the template does build-time expansion of the environment
      variables, it will expand the above line verbosely, and due to the
      envVar section not doing any further expansion the password variable
      will end up with the value "$(GITTEST_NEGOTIATE_PASSWORD)" in the
      container's environment.
      
      Fix this fixed by doing expansion of GITTEST_NEGOTIATE_PASSWORD at
      build-time, as well.
      Patrick Steinhardt committed
  4. 24 Jan, 2020 3 commits
  5. 03 Dec, 2019 1 commit
    • ci: only push docs from the libgit2/libgit2 repo · 9c30fbed
      Users may fork libgit2 and run libgit2's CI on that, which is
      delightful!  However, if they do, we'll fail the documentation publish
      phase, which is correct (because we don't allow them to publish _their_
      version of the docs) but regrettable (since it should not fail).
      
      Only run the documentation publish phase when we merge branches into the
      libgit2/libgit2 repo.
      Edward Thomson committed
  6. 24 Nov, 2019 1 commit
  7. 13 Oct, 2019 1 commit
  8. 21 Sep, 2019 1 commit
    • azure: avoid building and testing in Docker as root · 3c884cc3
      Right now, all tests in libgit2's CI are being executed as root
      user. As libgit2 will usually not run as a root user in "normal"
      usecases and furthermore as there are tests that rely on the
      ability to _not_ be able to create certain paths, let's instead
      create an unprivileged user "libgit2" and use that across all
      docker images.
      Patrick Steinhardt committed
  9. 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
  10. 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
  11. 18 Jul, 2019 1 commit
  12. 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
  13. 21 May, 2019 1 commit
  14. 28 Feb, 2019 2 commits
  15. 17 Feb, 2019 5 commits
  16. 14 Feb, 2019 2 commits
  17. 26 Jan, 2019 1 commit
    • ci: run docurium to create documentation · ace20c6a
      Run docurium as part of the build.  The goal of this is to be able to
      evaluate the documentation in a given pull request; as such, this does
      not implement any sort of deployment pipeline.
      
      This will allow us to download a snapshot of the documentation from the
      CI build and evaluate the docs for a particular pull request; before
      it's been merged.
      Edward Thomson committed
  18. 21 Oct, 2018 3 commits
  19. 19 Oct, 2018 2 commits
  20. 18 Sep, 2018 1 commit
  21. 06 Sep, 2018 1 commit