1. 12 Jul, 2019 2 commits
  2. 10 Jul, 2019 1 commit
  3. 29 May, 2019 2 commits
  4. 18 May, 2019 1 commit
    • Thomas Haller's avatar
      gitlab-ci: run unit tests under valgrind in gitlab-ci · 6d76a097
      Thomas Haller authored
      On Ubuntu 16.04 (trusty) valgrind fails due to rdrand being advertised
      but not implemented.
      
      Work around that by installing valgrind from Ubuntu 18.04 (bionic) via
      the "contrib/scripts/nm-ci-install-valgrind-in-ubuntu1604.sh" script.
      6d76a097
  5. 20 Apr, 2019 4 commits
  6. 19 Apr, 2019 4 commits
  7. 09 Apr, 2019 1 commit
    • Thomas Haller's avatar
      gitlab-ci: add test on Fedora 30 image · 2955d5e6
      Thomas Haller authored
      And no longer use "fedora:lastest". While "fedora:rawhide" names the very
      latest branch (and we want to test that), for all proper releases we want
      name them explicitly.
      2955d5e6
  8. 04 Apr, 2019 1 commit
  9. 09 Feb, 2019 1 commit
  10. 08 Feb, 2019 3 commits
  11. 07 Feb, 2019 1 commit
    • Thomas Haller's avatar
      gitlab-ci: build with clang and do multiple builds in one test-step · bdac03fe
      Thomas Haller authored
      Also, let one docker image do multiple builds. We fetch a fedora docker
      image, and then install 250 MB of packages. That alone takes a lot of
      time and resources. Instead of running a large number of docker images
      that only do one build, let one image do several builds.
      
      Also, install ccache. Hopefully this way we can benefit from
      building the same sources multiple times.
      
      Also note that building docs does not work currently with clang,
      due to g-ir-scanner. See commit 05568860.
      bdac03fe
  12. 27 Jan, 2019 1 commit
  13. 01 Dec, 2018 1 commit
  14. 12 Nov, 2018 1 commit
    • Thomas Haller's avatar
      ci: use common script for tests on travis and gitlab · 763cb8d4
      Thomas Haller authored
      For one, it's not unreasonable that we want to run the same
      tests both for gitlab and travis.
      
      Move the actual tests into a script, which is called by both
      CI environments.
      
      We still can do something different, based on the environment.
      The advantage here is, that the common part will be shared, and
      the places where we differ can easily be spot.
      
      !44
      763cb8d4
  15. 22 Oct, 2018 1 commit