Sentry-cli: Using GitLab CI with getsentry/sentry-cli:latest results in "Found argument 'sh' which wasn't expected, or isn't valid in this context"

[chrisforrence]

I'm using GitLab CI to send JavaScript files to Sentry with the following job:

Send files to Sentry:
  stage: post-build
  image: getsentry/sentry-cli
  dependencies:
    - build:production
  only:
    - master
  script:
    - echo "Uploading JavaScript files to Sentry..."
    - export SENTRY_URL=$SENTRY_BASE_URL
    - export SENTRY_AUTH_TOKEN=$SENTRY_BASE_TOKEN
    - export SENTRY_ORG=$SENTRY_BASE_ORGANIZATION
    - export SENTRY_PROJECT=$SENTRY_BASE_PROJECT
    - sentry-cli releases new $CI_COMMIT_SHA
    - sentry-cli releases files $CI_COMMIT_SHA upload-sourcemaps $CI_PROJECT_DIR/dist/static/js --url-prefix '~/static/js'
    - sentry-cli releases finalize $CI_COMMIT_SHA
    - echo "Finalized release for $CI_COMMIT_SHA"

This worked like a champ up until earlier today, when I started getting the following:

Running with gitlab-runner 10.8.0 (079aad9e)
  on cforrence.centos 17845938
Using Docker executor with image getsentry/sentry-cli ...
Pulling docker image getsentry/sentry-cli ...
Using docker image sha256:bbdb1a31e805d891be92c62af27c579559a4825023560944c8a8f5394bad065c for getsentry/sentry-cli ...
Running on runner-17845938-project-2-concurrent-0 via localhost.localdomain...
Cloning repository...
Cloning into '/builds/developers/repository'...
Checking out a853c499 as master...
Skipping Git submodules setup
Downloading artifacts for build:production (9426)...
Downloading artifacts from coordinator... ok        id=9426 responseStatus=200 OK token=eptYn1Jy
error: Found argument 'sh' which wasn't expected, or isn't valid in this context

USAGE:
    sentry-cli <SUBCOMMAND>

For more information try --help
error: Found argument 'sh' which wasn't expected, or isn't valid in this context

USAGE:
    sentry-cli <SUBCOMMAND>

For more information try --help
ERROR: Job failed: exit code 1

It looks like there had been an updated tag (1.35.2) released earlier today which had an entrypoint change. Explicitly using 1.35.1 caused the job to work as usual.

[mitsuhiko]

Sorry this made it accidentally into a patchlevel release. But since it would cause similar pain even if it was in a 1.36 we will probably try to find a soft migration path.

[tonyo]

@chrisforrence Sorry again for the confusion, version 1.35.3 should support both (the old and the new) command line formats, and it should show a deprecation warning if you use the old one.

[fones]

@tonyo I still have problems with version 1.35.3

Running with gitlab-ci-multi-runner 9.5.0 (413da38)
  on sc_dev (feb05a79)
Using Docker executor with image getsentry/sentry-cli:1.35.3 ...
Starting service mysql:5.6 ...
Pulling docker image mysql:5.6 ...
Using docker image mysql:5.6 ID=sha256:7edb93321b06db3c659d473ade22241b0d2eaa551c8479b9181672456293a0b9 for mysql service...
Waiting for services to be up and running...
Using docker image sha256:6eeb9e94e03b6ebc3f1b4202a8c9a588e575c23671e401ae52b4b4fea59c5e51 for predefined container...
Pulling docker image getsentry/sentry-cli:1.35.3 ...
Using docker image getsentry/sentry-cli:1.35.3 ID=sha256:9b0112a4bbf94b6b821cea11b1d08cd7abbf93053b3c364a9e81d99d9468d16a for build container...
Running on runner-feb05a79-project-3100370-concurrent-0 via d6c75f46e311...
Fetching changes...
HEAD is now at 7a6d0c9 Fix sentry CLI
Checking out 7a6d0c95 as master...
Skipping Git submodules setup
error: Found argument 'sh' which wasn't expected, or isn't valid in this context

USAGE:
    sentry-cli <SUBCOMMAND>

For more information try --help
error: Found argument 'sh' which wasn't expected, or isn't valid in this context

USAGE:
    sentry-cli <SUBCOMMAND>

For more information try --help
ERROR: Job failed: exit code 1

[tonyo]

@fones
Aha, looks like Gitlab tries to run something on the lines of docker run getsentry/sentry-cli sh. This format of execution was never part of the documentation or image interface.
Do you know why exactly Gitlab needs to run sh inside that container?

[fones]

@tonyo
Probably it uses it for getting ENV value, like $CI_COMMIT_SHA

sentry_test:
  image: getsentry/sentry-cli:1.35.3
  stage: notifytest
  script:
    - sentry-cli releases new -p socialproof-omega "$CI_COMMIT_SHA"
    - sentry-cli releases set-commits "$CI_COMMIT_SHA" --commit "fones/socialproof-omega@$CI_COMMIT_SHA"
    - sentry-cli releases finalize "$CI_COMMIT_SHA"
    - sentry-cli releases deploys "$CI_COMMIT_SHA" new -e production_test
  only:
    - master

[tonyo]

Ok, looks like Gitlab CI collects all directives from script and *_script into a script, and then runs it.
@fones Could you please try to test your configuration with getsentry/sentry-cli:1.35.3-sh image? It should also allow sh as the first argument for docker run.

In general, please take a look at https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image
In this sort of cases it is recommended to explicitly set an image entrypoint in your build, so there's no additional assumptions about the image interface.

[ianberinger]

I've run into the same issue. Overriding the entrypoint works great.

job_name:
  image: 
    name: getsentry/sentry-cli
    entrypoint: [""]
  script:
    - sentry-cli releases ...

I had to do the same thing for other images as well, most recently gcr.io/kaniko-project/executor:debug.

[chrisforrence]

Thank you @tonyo for investigating this (when it's more of a misconfiguration on my side). Explicitly setting getsentry/sentry-cli's entry point to [""] fixed the issue (also, thanks @ianberinger!)

[tonyo]

@chrisforrence glad we could help 👍
To facilitate migration to the updated entrypoint, versions 1.35.4+ of the image should throw a warning if you pass 'sh' as the first argument.