1. 28 Oct, 2020 4 commits
    • Dridi Boukelmoune's avatar
      ci: Increase parallelism in Travis CI builds · 1b606ff9
      Dridi Boukelmoune authored
      They are taking too long, needlessly holding onto job slots forever.
      
      Align with CircleCI for now, even though we could probably do more.
      1b606ff9
    • Dridi Boukelmoune's avatar
      cocci: Remove redundant AN() checks after REPLACE() · fda02024
      Dridi Boukelmoune authored
      Except those present in varnishtest/vtest.
      fda02024
    • Dridi Boukelmoune's avatar
      test: Over-breeding is still a thing · 1b0a51cc
      Dridi Boukelmoune authored
      Spotted on CircleCI:
      
          ---- v1    Not true: MAIN.threads (26) == 10 (10)
      
      Refs #2942
      1b0a51cc
    • Dridi Boukelmoune's avatar
      vtc: Add varnish macros for all listen addresses · c7ac5266
      Dridi Boukelmoune authored
      When a test case successfully runs this:
      
          varnish v1 -start
      
      The following macros are created:
      
      - ${v1_addr}
      - ${v1_port}
      - ${v1_sock}
      
      When v1 listens to a UNIX domain socket, those macros become useless and
      we generally have to repeat the socket path wherever we need it.
      
      From now on, varnish listen address macros for unix domain sockets match
      their server counterparts:
      
      - ${v1_addr} expands to "0.0.0.0"
      - ${v1_port} expands to "0"
      - ${v1_sock} expands to the socket path
      
      It is now possible to use the following construct regardless of the
      socket type:
      
          client c1 -connect "${v1_sock}"
      
      In addition, the debug.listen_address command now outputs the listen
      address name in addition to its endpoint. For example, in a test case
      with the following command:
      
          varnish v1 -arg "-a :0 -a :0 -b '${bad_backend}'" -start
      
      The output for debug.listen_address could look like this:
      
          a0 127.0.0.1 34567
          a0 ::1 34567
          a1 127.0.0.1 45678
          a1 ::1 45678
      
      The resulting macros would be:
      
      - ${v1_addr}
      - ${v1_port}
      - ${v1_sock}
      - ${v1_a0_addr}
      - ${v1_a0_port}
      - ${v1_a0_sock}
      - ${v1_a1_addr}
      - ${v1_a1_port}
      - ${v1_a1_sock}
      
      It becomes possible to reliably listen to multiple endpoints and use
      either in a test case. On a dual-stack system where we might end up
      with multiple endpoints sharing the same name, only the first one is
      used for a given name. In the example above all macros would expand
      to IPv4 addresses.
      c7ac5266
  2. 27 Oct, 2020 6 commits
  3. 26 Oct, 2020 13 commits
  4. 24 Oct, 2020 1 commit
  5. 23 Oct, 2020 3 commits
  6. 22 Oct, 2020 2 commits
  7. 21 Oct, 2020 11 commits