|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
c7e5eca6
|
2019-02-28T10:46:26
|
|
Revert "foo"
This reverts commit 1fe3fa5e59818c851d50efc6563db5f8a5d7ae9b.
|
|
|
1fe3fa5e
|
2019-02-28T10:44:34
|
|
foo
|
|
|
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.
|
|
|
b5b3aa93
|
2019-02-17T12:50:51
|
|
Revert "ci: publish documentation after merge"
This reverts commit 2a4e866a43e3db1e2be8e2a3d986ddc9f855d2bc.
|
|
|
4a02d24a
|
2019-02-17T12:40:20
|
|
foo
|
|
|
484fff87
|
2019-02-17T12:36:41
|
|
foo
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
28f05585
|
2018-10-21T09:20:10
|
|
ci: reorganize naming for consistency
|
|
|
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.
|
|
|
f77e6cc7
|
2018-10-19T17:10:01
|
|
ci: make the Ubuntu/OpenSSL build explicit
|
|
|
6a67e42d
|
2018-10-08T19:33:27
|
|
ci: use Ninja on macOS
|
|
|
d7d0139e
|
2018-09-18T13:35:25
|
|
ci: rename vsts to azure-pipelines
|