2

I have been playing around with K6 performance tests on GitLab CI and I am wondering what is the best and recommended approach for setup.

According to the K6 docs and sample project it defines the .gitlab-ci.yml as follows:

before_script:
  - mkdir -p .k6-bin
  - |
      if [[ ! -f .k6-bin/k6 ]]; then
        curl -O -L https://github.com/loadimpact/k6/releases/download/v0.21.1/k6-v0.21.1-linux64.tar.gz;
        tar -xvzf k6-v0.21.1-linux64.tar.gz;
        mv k6-v0.21.1-linux64/k6 .k6-bin/k6;
      fi

cache:
  key: k6-bin
  paths:
    - .k6-bin

loadtest:
    stage: test
    script: .k6-bin/k6 run -o cloud loadtests/main.js

I found this to be quite verbose especially when you consider a prebuilt docker image is made available. This approach would require manual updates when new versions are released and doesn’t seem as clean as the following configuration I am currently using:

loadtest:
  stage: test
  image:
    name: loadimpact/k6:latest
    entrypoint: [""]
  script: k6 run ./loadtests/main.js

Both work exactly as expected which is why I’m wondering whether the K6 team know something and don’t recommend the use of their docker image?

cdavid15
  • 413
  • 7
  • 14

1 Answers1

3

Ah, I am one of the people on the k6 team and in this case you are absolutely right - the docker approach is the better one. We'll fix the documentation and the example repo - https://github.com/loadimpact/k6/issues/1196. I don't know why they advocated the other approach - it was probably an old copy-paste from another CI system that doesn't work as well with containers as GitLab CI does. Case in point, the actual k6 version used is super old - v0.21.1 was released on Jun 4 2018. Thanks for pointing this out, we'll fix the docs and example in the upcoming days, so for now stick with your gut instead of our obsolete docs!

na--
  • 1,016
  • 7
  • 9