1. 25 May, 2021 10 commits
  2. 20 Apr, 2021 3 commits
  3. 13 Apr, 2021 1 commit
    • Daniel P. Berrangé's avatar
      Revert "Add a go.mod file to make build work with go 1.16" · 40e81f2f
      Daniel P. Berrangé authored
      This reverts commit 90777c79.
      
      Adding the go.mod file had unexpected consequences for consumers of the
      libvirt-go bindings, because in 1.16 it is not strongly enforced that
      libraries using modules are following semver versioning.
      
      The libvirt-go binding has always followed libvirt native API versions
      1:1 and thus uses calver, not semver.  All libvirt native API versions
      are backwards compatible indefinitely, and the Go bindings aim to keep
      the same promise. With this in mind, it would be wrong to re-interpret
      the current libvirt-go version tags as being semver, as that will
      appear like an ABI break once a year when libvirt changes major version.
      
      As a result of adding the go.mod file, consumers are unable to upgrade
      to libvirt-go > 7.0.0, because Go will refuse to use v7.1.0+incompatible
      references:
      
        go.mod:8:2: require github.com/libvirt.org/libvirt-go: version "v7.2.0" invalid: should be v0 or v1, not v7
      
      Effectively with modern Go, a program can only consume dependancies
      using calver if those deps do not provide a go.mod
      
      Changing libvirt-go to use semver would require choosing one of the
      various undesirable options
      
       1. Delete all existing tags and go back to a v1.<libvirt version>
          scheme. Trashing history is undesirable in general, and hard
          because Go module proxy server caches tags in a append-only,
          so will remember existing tags even if the repo deletes them.
      
       2. Rename the repo, and do (1), to get around the Go module proxy
          cache
      
       3. Pick a new major version (eg v10) and use v10.<libvirt version>
          here after. Move all files under the v10/ directory and have
          all consumers update to the new import path. This is declaring
          that the new version is incompatible with all previous versions
          which is not actually true. This needlessly creates an interop
          problem until all consumers have updated.
      
      The simplest way out of the problem in the short term at least, is
      to simply stop providing go.mod for libvirt-go, at which point the
      non-semver tags can be used by consumers as has been the case
      historicaly.
      
      There's a risk that future Go releases might get even more strict
      and eventually break non-semver usage even in the case without
      go.mod, but at that time we'll be no worse off then now. So it is
      worth just backtracking from use of go.mod for now.
      
      To deal with the problem 90777c79
      describes, we set GO111MODULE=auto to allow non-modular builds
      outside of a GOPATH hierarchy.
      
      Fixes #7
      
      Signed-off-by: Daniel P. Berrangé's avatarDaniel P. Berrangé <berrange@redhat.com>
      40e81f2f
  4. 12 Apr, 2021 2 commits
    • Daniel P. Berrangé's avatar
      gitlab: run api-coverage tests in a separate non-fatal job · 2e8aa7ef
      Daniel P. Berrangé authored
      
      
      The "api" go test tag verifies that the binding covers all APIs in the
      libvirt library/headers being built against. This is primarily there for
      libvirt maintainers to identify when there are gaps in API coverage.
      
      If people are working on branches or submitting merge requests for Go
      changes, we shouldn't block their work for failed API coverage tests,
      if the Go binding otherwise builds fine and passes regular unit tests.
      
      Thus, we introduce a new gitlab job "api-coverage" with some conditions:
      
       - If pushing to a branch, the job is treated as non-fatal
       - For regular scheduled builds, it is mandatory
       - Don't run in any other scenarios
      
      This job uses the artifacts from the centos-8-git-build job and re-runs
      the test suite, requesting the sanity tests to be run too.
      
      This will achieve the result of letting us see missing API coverage
      in nightly builds, without blocking other contributions.
      Signed-off-by: Daniel P. Berrangé's avatarDaniel P. Berrangé <berrange@redhat.com>
      2e8aa7ef
    • Daniel P. Berrangé's avatar
      gitlab: don't delay container/build phase for sanity tests · c16c14e0
      Daniel P. Berrangé authored
      
      
      The DCO job and Go fmt job are put in stage at the end of the pipeline,
      but with "needs: []" which lets them run before earlier stages are
      complete. This gives better parallelism in the build.
      Signed-off-by: Daniel P. Berrangé's avatarDaniel P. Berrangé <berrange@redhat.com>
      c16c14e0
  5. 01 Apr, 2021 1 commit
  6. 29 Mar, 2021 4 commits
  7. 15 Feb, 2021 1 commit
  8. 29 Jan, 2021 2 commits
  9. 28 Jan, 2021 2 commits
  10. 15 Dec, 2020 2 commits
  11. 04 Dec, 2020 6 commits
  12. 02 Dec, 2020 2 commits
  13. 23 Nov, 2020 1 commit
  14. 16 Nov, 2020 2 commits
  15. 12 Nov, 2020 1 commit