- 23 Nov, 2019 1 commit
-
-
The lsb-release command is missing on our images; just show the information from the file instead of relying on it.
Edward Thomson committed
-
- 22 Nov, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 20 Jul, 2019 4 commits
-
-
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 committed -
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 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 -
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
-
- 13 Feb, 2019 1 commit
-
-
Subtle changes in the host OS can have impacts in the CI system that may be hard to debug. We previously showed the results of `uname` which can be difficult to interpret. Provide more information where available.
Edward Thomson committed
-
- 10 Sep, 2018 1 commit
-
-
This reverts commit a2d73f56. Using clar to propagate the XML settings was a mistake.
Edward Thomson committed
-
- 06 Sep, 2018 1 commit
-
-
Edward Thomson committed
-
- 06 Aug, 2018 1 commit
-
-
During the conversion of our CI scripts in bf418f09 (ci: refactor unix ci build/test scripts, 2018-07-14), we accidentally dropped the "-DENABLE_WERROR=ON" switch in our cmake invocation. Re-add it to help us catch compiler warnings early.
Patrick Steinhardt committed
-
- 03 Aug, 2018 1 commit
-
-
This change adds support for building a fuzz target for exercising the packfile parser, as well as documentation. It also runs the fuzzers in Travis to avoid regressions.
lhchavez committed
-
- 26 Jul, 2018 3 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-