azure-pipelines


Log

Author Commit Date CI Message
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 4e07a205 2019-08-02T13:29:54 docker: fix Valgrind errors on Xenial by updating to v3.12.0 The Valgrind version shipped with Xenial has some bugs that keep our tests from working due to bad interactions with openssl [1]. Fix this by using the "hola-launchpad/valgrind" PPA that provides a newer version for which the bug has been fixed. [1]: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1574437
Patrick Steinhardt 3c59d451 2019-08-02T12:34:10 docker: use "--no-install-recommends" to reduce build time Pass the flag "--no-install-recommends" to apt-get in order to trim down the number of packages installed, both reducing build time and image size. As this also causes some required packages to not be installed anymore, add these explicitly to the set of packages installed.
Patrick Steinhardt 39b7e8b0 2019-08-02T12:26:30 docker: convert apt-get to use best practices Reformat both Xenial and Bionic's Dockerfiles to use best practices. Most importantly, we now run `apt-get update` and `apt-get install` in one step followed up by removing the package lists to speed up installation and keep down the image size.
Patrick Steinhardt 9f91d57e 2019-08-02T14:25:02 docker: install libssh2 1.8.2 on Xenial While Xenial provides libssh2 in its repositories, it only has version 1.5.0 available. This version will unfortunately not be able to connect to GitHub due to their removal of weak cryptographic standards [1]. To still enable our CI to execute tests against GitHub, we thus have to update the provided libssh2 version to a newer one. Manually install libssh2 1.8.2 on Xenial. There's no need to do the same for Bionic, as it already provides libssh2 1.8.0. [1]: https://github.blog/2018-02-01-crypto-removal-notice/
Patrick Steinhardt 253dbea2 2019-08-02T10:21:32 docker: install mbedTLS on both Bionic and Xenial We're about to phase out support for Trusty, but neither Bionic nor Xenial images provide the mbedTLS library that's available in Trusty. Build them for both to pull them in line with Trusty.
Patrick Steinhardt bbc0b20b 2019-08-02T10:27:24 azure: fix Coverity's build due to wrong container name The Coverity build is still referencing an old "trusty-openssl" container that is not provided by either our own now-inlined images nor by the libgit2/libgit2-docker repository. Convert it to build and use Xenial images instead.
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 415ee616 2019-07-12T09:40:13 azure-pipelines: make gitdaemon tests work on Win32 On Win32 builds, the PID file created by git-daemon contained in invalid PID that we were not able to kill afterwards. Somehow, it seems like the contained PID was wrapped in braces. Consequentially, kill(1) failed and thus caused the build to error. Fix this by directly grabbing the PID of the spawned git-daemon process.
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 1be4f896 2019-07-19T12:07:59 azure: avoid executing compiler if there is none Until now, we always had the CC variable defined in the build.sh pipeline. But as we're about to migrate the Windows jobs to Bash, as well, those will not have CC defined and thus we cannot use "$CC" to determine the compiler version. Fix this by only executing "$CC" if the variable was set.
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 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 ef91917f 2019-02-14T09:19:32 ci: skip ssh tests on macOS nightly Like 811c1c0f8f80521dccc746a7bff180cd77a783ff, disable the SSH tests on macOS until we can resolve the newly introduced infrastructure issues.
Edward Thomson 0cf5b6b1 2019-01-28T10:48:49 ci: ignore coverity failures in nightly runs Coverity is back but it's only read-only! Agh. Just allow it to fail and not impact the overall job run.
Edward Thomson 08d71f72 2019-01-27T22:46:07 ci: return coverity to the nightlies
Edward Thomson 4a798a91 2018-10-28T17:57:53 nightly: use latest images, not test images
Edward Thomson 1ebf3a7d 2019-01-19T00:34:55 ci: only run invasive tests during nightly runs
Etienne Samson 3c6d1979 2019-01-11T02:06:41 ci: move coverity in its own pipeline Since Coverity is down for a unspecified timeframe, isolate it from the "hosted" nightlies.
Edward Thomson f195c385 2018-10-26T14:10:13 nightly: the path to yaml templates is relative Don't prefix the path to the yaml templates - the nightly template itself is already in the `azure-pipelines` directory. Instead, just use the relative path.
Edward Thomson be5a2ae2 2018-10-25T23:19:42 ci: run all the jobs during nightly builds Instead of running the oddball builds, run all the builds (the ones that we always run during PR validation and CI) during a nightly build for increased coverage.
Edward Thomson d82800e8 2018-10-21T09:31:42 ci: use bionic for non-amd64 builds Use Bionic so that we have a modern libssh2 (for communicating with GitHub). We've ported fixes to our Trusty-based amd64 images, but maintaining patches for multiple platforms is heinous.
Edward Thomson b244ea79 2018-10-21T09:24:08 ci: introduce nightly x86 linux builds
Edward Thomson 0e521abd 2018-10-21T09:15:24 ci: introduce nightly arm docker builds Use multiarch arm32 and arm64 docker images to run Xenial-based images for those platforms. We can support all the tests on ARM32 and 64 _except_ the proxy-based tests. Our proxy on ARM seems regrettably unstable, either due to some shoddy dependencies (with native code?) or the JREs themselves. Run these platforms as part of our nightly builds; do not run them during pull request or CI validation.
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.