Warning: separate entrypoint breaks CI pipelines

[MatteoJoliveau]

Hi, not an issue per se, but I wanted to raise a warning for those who (like myself) use this image for Docker-based pipelines like Gitlab CI.

Since the split of entrypoint and cmd pipelines fail because the underlying engine is (probably) running bash -c $MYCOMMANDS as a custom CMD.

Since now we have sonar-scanner as the entrypoint, I get errors like ERROR: Unrecognized option: -c because it's passing it to sonar-scanner.

The solution is to override the image entrypoint in the pipeline, for example by setting (Gitlab CI syntax):

analysis:
  stage: analysis
  image:
    name: newtmitch/sonar-scanner:3.2-alpine
    entrypoint: ['']
  dependencies:
    - tests
  script:
    - sonar-scanner -Dsonar.host.url=$SONAR_URL -Dsonar.login=$SONAR_TOKEN -Dsonar.projectBaseDir=.

I hope it can be useful to others. Thanks for the image, btw!

[newtmitch]

Thanks for the feedback, @MatteoJoliveau! I don't use this in a pipeline at all and don't really have the capability to test this out. Is there a better way to separate the CMD and ENTRYPOINT directives in the Dockerfile so it doesn't require such a hacky workaround? I made this change to solve someone else's issue with the way it was oriented before and also to align more closely with Docker's best practices for CMD and ENTRYPOINT usage. Clearly this broke some other stuff (sorry!).

[mhodgson]

Yeah, probably best to make a new tag for a breaking change like this. When you change the entrypoint it is very likely to break any type of automated usage. Anyway, thanks for publishing the image!

[MatteoJoliveau]

No need to apologize, @newtmitch! It's difficult to please everyone. I think the best approach is the one proposed by @mhodgson. You could make a new Dockerfile without the ENTRYPOINT (you can even use it as a base for the regular one to reuse code!) and tag it with something like 3.2-alpine-ci so that we know it's best suited for automated use.

[YohanAlard]

Hi @newtmitch!, have you planned to add a ci version soon without entrypoint ? Matteo workaround will work for gitlab > 9.4

[jeremych1000]

Agreed. Additionally, I'd recommend not touching old tags and instead increment the version - was using 3.2.0-alpine and wondered why it broke suddenly :P

Here's an output from Jenkins for reference.

docker run -t -d -u 1000:1000 -v $PWD:/root/src -w /home/jenkins-slave/workspace/<redacted>@2 --volumes-from <redacted> -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** newtmitch/sonar-scanner:3.2.0-alpine cat
ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).
Alternatively you can force image entrypoint to be disabled by adding option `--entrypoint=''`.

[newtmitch]

I just refactored the Dockerfile and simplified the repo while doing so. Part of that refactor was moving back to the CMD-based usage rather than the ENTYRPOINT+CMD-based usage, which should simplify the image's usage for use-cases like CI. I've left existing images as-is in order to maintain current usage (and not break things again!) and also created a 4.0-ci tag specifically to address this issue. All image tags 4.1 and later have been updated to use CMD only.

Closing this issue. Thanks for all the discussion here!