docker-compose setup stopped working with the new version of k6.
docker-compose run k6 run scripts/es6sample.js
Creating k6_k6_run ... done
WARN[0000] The moduleSpecifier "scripts/es6sample.js" has no scheme but we will try to resolve it as remote module. This will be deprecated in the future and all remote modules will need to explicitly use "https" as scheme.
ERRO[0020] The moduleSpecifier "scripts/es6sample.js" couldn't be found on local disk. Make sure that you've specified the right path to the file. If you're running k6 using the Docker image make sure you have mounted the local directory (-v /local/path/:/inside/docker/path) containing your script and modules so that they're accessible by k6 from inside of the container, see https://k6.io/docs/using-k6/modules#using-local-modules-with-docker. Additionally it was tried to be loaded as remote module by prepending "https://" to it, which also didn't work. Remote resolution error: "Get "https://scripts/es6sample.js"
@jeevananthank Were you relying on this particular command?
We changed the WORKDIR of the default image to /home/k6 to avoid some permission issues other users were getting tripped by, as mentioned in the Breaking Changes of the release notes.
So using an absolute path should work in this case: docker-compose run k6 run /scripts/es6sample.js.
Thanks for reporting this! We are going to move the docker-compose file away from the k6 repo eventually (Clean up external examples and configs · Issue #1614 · grafana/k6 · GitHub), but the question is how to fix it before that? Do we even need the volumes, considering the currently configured volume wouldn’t be useful for users that actually want to use their own scripts and not our demo samples?
Can you post your modified docker-compose.yml? Because from the root of the k6 repo with the unmodified file ./samples will be mounted at /scripts inside the container and the absolute path works for me on Linux, and I don’t see why it wouldn’t on Windows.
Only other thing I would try is docker-compose down -v to remove the volumes and docker-compose up or that run command with the absolute path.
OK, I found a working workaround… It works if you run either:
docker-compose run k6 run //scripts//es6sample.js
Or:
MSYS_NO_PATHCONV=1 docker-compose run k6 run /scripts/es6sample.js
Confirmed this works with Git Bash 2.29.2 and Docker 20.10.2 installed via Docker Desktop on Windows 10 Pro.
It’s an issue caused by MSYS2’s path conversion, which for some reason wasn’t an issue when the WORKDIR was /, but is when you specify absolute paths like this.
You can see additional details about this in this issue and ways to enable the env var globally.
My suggestion though would be to avoid using Docker from the Git Bash (MSYS2) terminal, as there are several translation layers involved besides the already complex Hyper-V and WSL2 requirements for Docker on Windows, any of which can cause unexpected issues. So I would use Docker from cmd.exe or PowerShell to at least avoid some of that complexity.
It works if you run either: