azure-pipelines.yml


Log

Author Commit Date CI Message
Edward Thomson 8b8b69a7 2020-06-10T22:13:25 azure pipelines: use bundled zlib Azure Pipelines has a version of zlib hanging out on the filesystem; avoid trying to use it as it's either 64 _or_ 32 bit, so exactly one of our builds will fail.
Patrick Steinhardt 95f329b4 2020-03-10T21:07:34 azure: upgrade to newer hosted VM images Azure is phasing out old images on March 23rd 2020, but we're currently still using them. So let's upgrade images as following: - Ubuntu 16.04 -> ubuntu-18.04 - macOS 10.13 -> macOS-10.15 - Hosted Windows machines -> vs2017-win2016 Each of them is currently the latest version. As the new Microsoft Windows machine has upgraded to MSVS2017, we need to also adjust our CMake generators to "Visual Studio 15 2017". As this CMake generator doesn't accept the target platform name anymore, we instead need to set it up via either "-A Win32" or "-A x64". [1]: https://devblogs.microsoft.com/devops/removing-older-images-in-azure-pipelines-hosted-pools/
Patrick Steinhardt 877054f3 2020-02-10T12:35:13 cmake: consolidate Valgrind option 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 d827b11b6 (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 7aa99dd3 2020-01-31T11:41:43 azure-pipelines: properly expand negotiate passwords To allow testing against a Kerberos instance, we have added variables for the Kerberos password to allow authentication against LIBGIT2.ORG in commit e5fb5fe5a (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.
Edward Thomson da9bc8ac 2019-11-27T23:42:16 ci: enable GSSAPI for Ubuntu builds
Edward Thomson 031e3e4c 2019-11-27T14:20:44 ci: don't do negotiate tests on windows We can't get a kerberos TGT easily on Windows; skip the negotiate tests.
Edward Thomson e5fb5fe5 2019-10-20T17:19:01 ci: perform SPNEGO tests Attempt to obtain a Kerberos ticket from LIBGIT2.ORG and then clone the Negotiate-protected site at test.libgit2.org with that ticket.
Edward Thomson 9c30fbed 2019-12-03T18:09:03 ci: only push docs from the libgit2/libgit2 repo 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 c863b3c8 2019-11-24T16:49:23 ci: enable the VALGRIND flag on builds
Etienne Samson 3e862514 2019-09-21T22:50:27 azure: enable GSS on macOS builds
Patrick Steinhardt 3c884cc3 2019-09-21T15:05:36 azure: avoid building and testing in Docker as root 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 48d23a8c 2019-08-02T12:36:19 azure: convert to use Ninja as build tool 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 76327381 2019-08-02T10:50:11 azure: deprecate Trusty in favor of Xenial 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 5a6740e7 2019-08-02T09:58:55 azure: build Docker images as part of the pipeline 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 f867bfa8 2019-07-20T18:35:46 azure: skip SSH tests on Win32 platforms 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 0cda5252 2019-07-19T12:09:58 azure: use bash scripts across all platforms 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 8e356f48 2019-07-20T18:35:20 azure: explicitly specify CMake generator 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 443df2df 2019-06-24T16:27:00 azure: replace mingw setup with bash 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 d8e85d57 2019-06-27T15:01:24 azure: fix building in MinGW via Bash 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 ffac520e 2019-06-24T16:19:35 azure: move build scripts into "azure-pipelines" directory 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 d827b11b 2019-06-28T13:20:54 tests: execute leak checker via CTest directly 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 270fd807 2019-07-18T13:44:10 azure: compile one Windows platform with the WinHTTP SHA1 backend We currently have no job that compiles libgit2 with the WinHTTP backend for SHA1. Due to this, a compile error has been introduced and not noticed for several months. Change the x86 MSVC job to use the HTTPS backend for SHA1. The x86 job was chosen with no particular reason.
Etienne Samson 94fc83b6 2019-06-13T16:48:35 cmake: Modulize our TLS & hash detection 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.
Edward Thomson afb04a95 2019-05-21T14:03:04 ci: use a mix of regex backends Explicitly enable the `builtin` regex backend and the PCRE backend for some Linux builds.
Edward Thomson c7e5eca6 2019-02-28T10:46:26 Revert "foo" This reverts commit 1fe3fa5e59818c851d50efc6563db5f8a5d7ae9b.
Edward Thomson 1fe3fa5e 2019-02-28T10:44:34 foo
Edward Thomson fbfa41a1 2019-02-17T19:07:37 ci: publish documentation on merge When a commit is pushed or merged into one of the release branches (master, maint/*) then push the documentation update to gh-pages.
Edward Thomson b5b3aa93 2019-02-17T12:50:51 Revert "ci: publish documentation after merge" This reverts commit 2a4e866a43e3db1e2be8e2a3d986ddc9f855d2bc.
Edward Thomson 4a02d24a 2019-02-17T12:40:20 foo
Edward Thomson 484fff87 2019-02-17T12:36:41 foo
Edward Thomson 2a4e866a 2019-02-17T12:34:23 ci: publish documentation after merge When a continuous integration build runs (ie a commit is pushed or merged into one of the CI branches, `master` or `maint/*`) then push the rebuilt documentation into the `gh-pages` branch.
Edward Thomson 3f823c2b 2019-02-14T00:00:06 ci: enable hard deprecation Enable hard deprecation in our builds to ensure that we do not call deprecated functions internally.
Edward Thomson 811c1c0f 2019-02-14T00:51:39 ci: skip ssh tests on macOS SSH tests on macOS have begun failing for an unknown reason after an infrastructure upgrade to macOS 10.13.6. Disable those tests temporarily, until we can resolve it.
Edward Thomson ace20c6a 2019-01-26T16:59:32 ci: run docurium to create documentation 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 7c557169 2018-10-21T10:34:38 ci: use trusty-amd64 for openssl and mbedtls We don't need two separate docker images for OpenSSL and mbedTLS. They've been combined into a single image `trusty-amd64` that supports both.
Edward Thomson 28f05585 2018-10-21T09:20:10 ci: reorganize naming for consistency
Edward Thomson 4ec597dc 2018-10-21T09:12:43 ci: move configuration yaml to its own directory As the number of each grow, separate the CI build scripts from the YAML definitions.
Etienne Samson f77e6cc7 2018-10-19T17:10:01 ci: make the Ubuntu/OpenSSL build explicit
Etienne Samson 6a67e42d 2018-10-08T19:33:27 ci: use Ninja on macOS
Edward Thomson d7d0139e 2018-09-18T13:35:25 ci: rename vsts to azure-pipelines