k6-dev-tool container

[olegbespalov]

What?

This PR introduces the possibility to build a k6-dev-tools container that contributors/maintainers can use during the development. The idea is to keep "locked" the versions of the tools there and use this for the common operations like running the linter, applying the auto-fixes, code generation, and so on (the origin from there https://github.com/grafana/k6/pull/2437#discussion_r850159605).

How to use it?

Build it with

make make build-k6-dev-tools

Then run either:

make lint

or

make fix

or

make generate

Why?

It improves the developer's UX, and I believe should help external maintainers.

[javaducky]

Just a side comment about the Makefile. WDYT about adding a make help target which lists the targets with descriptions. An example is here.

This would allow folks to see the available targets as the following:

$ make help
Usage: make <OPTIONS> ... <TARGETS>

Available targets are:

  help           Prints a list of available build targets.
  clean          Removes any previously created build artifacts.
  build          Builds the 'xk6' binary.
  build-docker
  format         Applies Go formatting to code.
  test           Executes any unit tests.
  vendor         Pulls source for external dependencies.

Targets run by default are: clean, format, test, and build

[javaducky]

Not sure why the linting via Docker is such a significant time difference... 1.5m versus 11s.

~/Develop/k6  feat/docker-dev ✔                                                                                                                                2h31m  
▶ time make lint
make lint  0.06s user 0.06s system 0% cpu 1:30.46 total

~/Develop/k6  feat/docker-dev ✔                                                                                                                                2h32m  
▶ time golangci-lint run --fix --new-from-rev master ./...
golangci-lint run --fix --new-from-rev master ./...  15.86s user 1.31s system 151% cpu 11.336 total

EDIT: Looking at Docker setup, I've allowed 4 CPUs and 8.00GB for memory.

[olegbespalov]

@javaducky yeah, make help is a nice thing, added

Not sure why the linting via Docker is such a significant time difference... 1.5m versus 11s.

I guess it's related to the cache (the previous implementation has it). I return now should be better (after the first run).

[javaducky]

Adding the lint cache for Docker made a marked improvement after the initial run!

make lint  0.06s user 0.04s system 0% cpu 1:43.18 total

~/Develop/k6  feat/docker-dev ✔                                                                                                                                  21m  
▶ time make lint
make lint  0.06s user 0.04s system 0% cpu 24.079 total

~/Develop/k6  feat/docker-dev ✔                                                                                                                                  21m  
▶ time make lint
make lint  0.06s user 0.04s system 0% cpu 24.218 total

[javaducky]

LGTM if there are no objections from others with the switch to Docker tooling. 👍

[olegbespalov]

@na-- I see your point, but the idea is to help all maintainers/contributors (maybe even the external are the first audience). I thought that docker, in that case, was the best approach.

If the only size is the case, let me try to iterate on that. I believe there are still possible improvements without decreasing Dockerfile's maintainability.

[na--]

Yeah, the size is a big part of it, but not all of it. Personally, given my already existing Go development setup, I see no reason whatsoever to introduce any docker overhead. And this PR changes the Makefile in a way that tries to force me, switching all of the commands to use the docker image.

Previously we had both lint and ci-like-lint and you could use whatever you preferred, now everything is through Docker. I'd be fine with merging something like this if there are separate Makefile targets with and without docker, so everyone can choose what they prefer.

[olegbespalov]

Closed since not sure if it's relevant in general