|
47fb33ba
|
2020-06-07T00:39:27
|
|
Introduce CI with GitHub Actions
Add CI using GitHub Actions and GitHub Packages:
* This moves our Linux build containers into GitHub Packages; we will
identify the most recent commit that updated the docker descriptions,
and then look for a docker image in libgit2's GitHub Packages registry
for a container with the tag corresponding to that description. If
there is not one, we will build the container and then push it to
GitHub Packages.
* We no longer need to manage authentication with our own credentials or
PAT tokens. GitHub Actions provides a GITHUB_TOKEN that can publish
artifacts, packages and commits to our repository within a workflow
run.
* We will use a matrix to build our various CI steps. This allows us
to keep configuration in a single place without multiple YAML files.
|
|
|
767990e9
|
2019-11-23T11:25:38
|
|
ci: show distribution information
The lsb-release command is missing on our images; just show the
information from the file instead of relying on it.
|
|
|
91ba65af
|
2019-11-23T10:58:38
|
|
ci: provide a default for xcode generator
Provide a sane default for `CMAKE_GENERATOR` in the build script so that
it can be invoked without having to set that in the environment.
|
|
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.
|
|
|
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.
|
|
|
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.
|