1. 06 Feb, 2020 3 commits
  2. 05 Feb, 2020 7 commits
  3. 04 Feb, 2020 3 commits
  4. 03 Feb, 2020 6 commits
  5. 02 Feb, 2020 5 commits
    • Jérome Perrin's avatar
      slapos.cookbook/testing: fix missing version pin for mock · 826042a9
      Jérome Perrin authored
      Because we run egg tests with setup.py test, which installs missing
      eggs, if an egg was not installed by buildout, then it installed before
      running test. This was the case for mock, which is now python3 only (
      https://pypi.org/project/mock/4.0.0b1/ ) and we started to see test
      failures.
      
      To solve this issue, refactor the setup definition to use
      extra_requires, which seems to work fine in buildout now. Keep
      test_requires because it's the what `python setup.py test` uses.
      
      Clean buildout profiles to install slapos.cookbook[test] for test
      instead of duplicating the content of test_requires.
      
      /reviewed-on nexedi/slapos!690
      826042a9
    • Jérome Perrin's avatar
      software/grafana: version up and include loki/promtail · ab7ac63a
      Jérome Perrin authored
      This enable vieiwing applications logs directly in grafana, as long as
      loki agent can access the log file and the regular expressions to parse
      the logs are defined
      
      Other changes:
       - provision data sources automatically so that user do not have to add
         them manually
       - update TODO in README
       - introduce a SR test
       - switch to dep to install dependencies, because that's how these
        packages manage their dependencies.
      
      Versions up:
        grafana: v6.3.0
        telegraf: v1.11.1-0
        influxdb: v1.7.8rc1
      New:
        loki: v0.3.0
      ab7ac63a
    • Jérome Perrin's avatar
      software/grafana: version up go to 1.12 · fe0495be
      Jérome Perrin authored
      fe0495be
    • Jérome Perrin's avatar
    • Jérome Perrin's avatar
      component/golang: set gcc's path in workspace's PATH · 4b832215
      Jérome Perrin authored
      It seems some programs can only be built by the same gcc than the one used to
      build golang itself.
      
      For example, when system gcc is gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516,
      grafana-server fail to build with:
      
          /data/slappart11_testnode/cqg/inst/test0-0/tmp/shared/golang1.12/fbee59cfb3c995382cf70d409615aa54/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
          /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
          /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
          /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
          /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info
          /tmp/go-link-305363633/000000.o: file not recognized: File format not recognized
          collect2: error: ld returned 1 exit status
      
      Also generally, if we don't trust system gcc to build golang, we cannot trust
      it to build golang programs.
      
      The downside is that if components or software want to use a specifig
      golang version they have to set both golang= and the corresponding
      gcc-bin-directory= in their [gowork]
      4b832215
  6. 30 Jan, 2020 3 commits
  7. 29 Jan, 2020 8 commits
  8. 28 Jan, 2020 1 commit
  9. 22 Jan, 2020 4 commits