shellcheck --version or "online"): 0.4.6stable and the default (see below)When using the official Shellcheck Docker container for builds on GitLab CI the script commands are not run as expected.
# FILE: .gitlab-ci.yml
---
shellcheck:
stage: build
image: koalaman/shellcheck
script:
- shellcheck files/*/*.sh
The (relevant) output of the build job:
unrecognized option `-c'
Usage: shellcheck [OPTIONS...] FILES...
-a --check-sourced Include warnings from sourced files
-C[WHEN] --color[=WHEN] Use color (auto, always, never)
-e CODE1,CODE2.. --exclude=CODE1,CODE2.. Exclude types of warnings
-f FORMAT --format=FORMAT Output format (checkstyle, gcc, json, tty)
-s SHELLNAME --shell=SHELLNAME Specify dialect (sh, bash, dash, ksh)
-V --version Print version information
-x --external-sources Allow 'source' outside of FILES
The same happens when you run the docker container from within a terminal like this:
$ docker run --rm koalaman/shellcheck -c shellcheck files/*/*.sh
unrecognized option `-c'
Usage: shellcheck [OPTIONS...] FILES...
-a --check-sourced Include warnings from sourced files
-C[WHEN] --color[=WHEN] Use color (auto, always, never)
-e CODE1,CODE2.. --exclude=CODE1,CODE2.. Exclude types of warnings
-f FORMAT --format=FORMAT Output format (checkstyle, gcc, json, tty)
-s SHELLNAME --shell=SHELLNAME Specify dialect (sh, bash, dash, ksh)
-V --version Print version information
-x --external-sources Allow 'source' outside of FILES
So, it looks like GitLab CI is running the script: commands with a -c parameter to the image, or so. (I'm guessing!)
The commands in the script: section should be run just normally from within the Docker container.
A number of other containers work like this, e.g. composer has its own entrypoint script that seems to handle command line arguments gracefully. But simpler approaches exist, e.g. hoto/flake8 or mathow/centos-puppet-pdk.
Interestingly, other Docker images behave similarly, e.g. eeacms/flake8, which also complains about a -c option:
Usage: flake8 [options] input ...
flake8: error: no such option: -c
I don't know how GitLab CI works, but I'm guessing it intended to run sh -c 'shellcheck files/*/*.sh'. This will not work in the koalaman/shellcheck image because it does not have sh installed.
There's koalaman/shellcheck-alpine which does, but it's not set as the default entry point. You can run it with:
docker run --entrypoint=sh koalaman/shellcheck-alpine -c 'shellcheck /etc/*/*/*'
The GitLab CI docs say that there's an entrypoint option, maybe that needs to be explicitly set?
The proper way of running the main image does not have a any -c anywhere:
docker run -v "$PWD:/mnt" koalaman/shellcheck files/*/*.sh
The proper way of running the main image does not have a any -c anywhere
Just saying that GitLab CI behaves like this.
Same behavior with koalaman/shellcheck-alpine either. Would it be okay for you to change the default entry point to sh in order to make the image work with GitLab in its natural fashion?
It might be an option to make a shellcheck-gitlab image, but it seems weird to change the entry point to sh for this one strangely behaved service
As I mentioned above there are quite a few other images that do not define themselves to be made to work with "strangely behaved" services. They're just well designed.
koalaman/shellcheck and koalaman/shellcheck-alpine seem to be designed for local, manual execution (i.e. docker run ...) only. This reduces the usefulness of the image. I'm not saying this is necessarily bad, but with just a few changes it may be possible to make the image(s) be generally useful. For both manual execution and in CI environments as base images (as the ones mentioned above).
Ok, I'm convinced. It makes sense for koalaman/shellcheck-alpine to behave like an alpine image and not like a shellcheck image. I'll fix this when I get a chance.
Thanks! Great decision!
Could you try it again now?
Not 100% sure, but I think the behavior is still the same:
$ docker run --rm koalaman/shellcheck -c shellcheck ./scripts/foobar.sh
Unable to find image 'koalaman/shellcheck:latest' locally
latest: Pulling from koalaman/shellcheck
04360304a42b: Pull complete
e3a4e5d0de63: Pull complete
Digest: sha256:78ca37b19775167f1bde39f1e23a2f415baf7f44d12a75f68998c1694f6e80b3
Status: Downloaded newer image for koalaman/shellcheck:latest
unrecognized option `-c'
Usage: shellcheck [OPTIONS...] FILES...
-a --check-sourced Include warnings from sourced files
-C[WHEN] --color[=WHEN] Use color (auto, always, never)
-e CODE1,CODE2.. --exclude=CODE1,CODE2.. Exclude types of warnings
-f FORMAT --format=FORMAT Output format (checkstyle, gcc, json, tty)
-s SHELLNAME --shell=SHELLNAME Specify dialect (sh, bash, dash, ksh)
-V --version Print version information
-x --external-sources Allow 'source' outside of FILES
Running shellcheck using the image against local scripts doesn't seem to work either:
$ docker run --rm koalaman/shellcheck ./scripts/foobar.sh
./scripts/foobar.sh: ./scripts/foobar.sh: openBinaryFile: does not exist (No such file or directory)
Using the image as described in the README is still supported though:
$ docker run -v "$PWD:/mnt" koalaman/shellcheck ./scripts/foobar.sh
$ echo $?
0
Oh, just figured you refer to the koalaman/shellcheck-alpine image! I need more time to verify this. Sorry for the noise!
I can confirm the following snippet in a GitLab CI configuration file works as expected:
shellcheck:
image: koalaman/shellcheck-alpine
script: shellcheck *.sh
Hence, I'm closing this issue.
Most helpful comment
I can confirm the following snippet in a GitLab CI configuration file works as expected:
Hence, I'm closing this issue.