1. 09 Feb, 2023 1 commit
    • ci: convert PATH correctly to Cygwin format on Windows · b857122f
      We provide `BUILD_PATH` to our build script; provide it and mutate
      `PATH` when running our tests as well.
      
      We were previously using `cygpath` to try to convert a _list_ of Windows
      paths into cygwin / Unix style `PATH` format. This does not work -- it
      treats the path list as a single path (with semicolons -- understandably
      as those are allowed characters in a Windows path).
      
      For example, `C:\One;C:\Two;C:\Three` is converted to
      `/c/one;c:/two;c:/three`.
      
      Add a new function to convert path lists, so that paths are split by
      semicolon and fed to `cygpath` independently, then re-joined with a
      colon. This means that our example `C:\One;C:\Two;C:\Three` is correctly
      converted to `/c/one:/c/two:/c/three`.
      Edward Thomson committed
  2. 28 Feb, 2022 1 commit
  3. 15 Jan, 2021 1 commit
  4. 18 Nov, 2020 1 commit
  5. 09 Jul, 2020 1 commit
    • Add CI support for Memory and UndefinedBehavior Sanitizers · 6a917c04
      This change adds two new build targets: MSan and UBSan. This is because
      even though OSS-Fuzz is great and adds a lot of coverage, it only does
      that for the fuzz targets, so the rest of the codebase is not
      necessarily run with the Sanitizers ever :( So this change makes sure
      that MSan/UBSan warnings don't make it into the codebase.
      
      As part of this change, the Ubuntu focal container is introduced. It
      builds mbedTLS and libssh2 as debug libraries into /usr/local and as
      MSan-enabled libraries into /usr/local/msan. This latter part is needed
      because MSan requires the binary and all its dependent libraries to be
      built with MSan support so that memory allocations and deallocations are
      tracked correctly to avoid false positives.
      lhchavez committed
  6. 16 Jun, 2020 1 commit
    • Introduce CI with GitHub Actions · 47fb33ba
      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.
      Edward Thomson committed
  7. 23 Nov, 2019 1 commit
  8. 22 Nov, 2019 1 commit
  9. 20 Jul, 2019 4 commits
    • azure: avoid executing compiler if there is none · 1be4f896
      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
    • azure: explicitly specify CMake generator · 8e356f48
      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: fix building in MinGW via Bash · d8e85d57
      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
    • azure: move build scripts into "azure-pipelines" directory · ffac520e
      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
  10. 13 Feb, 2019 1 commit
  11. 10 Sep, 2018 1 commit
  12. 06 Sep, 2018 1 commit
  13. 06 Aug, 2018 1 commit
  14. 03 Aug, 2018 1 commit
  15. 26 Jul, 2018 3 commits