Sentry-cli: "A project slug is required" for upload-sourcemaps in GitLab CI

Created on 12 Dec 2018  路  11Comments  路  Source: getsentry/sentry-cli

$ sentry-cli releases files $VERSION upload-sourcemaps --rewrite ./dist/ --url-prefix /usr/src/app/
Analyzing 4 sources
Rewriting sources
Adding source map references
error: A project slug is required

Add --log-level=[info|debug] or export SENTRY_LOG_LEVEL=[info|debug] to see more output.

This seems related to #95. The release was previously created using sentry-cli.

$ sentry-cli releases new -p $PROJECT $VERSION
Created release c4ea65d6fd63f468eb69ac3a9d996c1f9521c764.
$ sentry-cli releases set-commits --auto $VERSION
+---------------+--------------+
| Repository    | Revision     |
+---------------+--------------+
| < REPO NAME > | c4ea65d6fd63 |
+---------------+--------------+

Most helpful comment

The command doesn't seem to accept a project slug argument, but you can export the SENTRY_PROJECT environment variable and it will be picked up.

All 11 comments

Can confirm the same issue. Is there a workaround to this?

The command doesn't seem to accept a project slug argument, but you can export the SENTRY_PROJECT environment variable and it will be picked up.

Can you add --project option to sentry-cli releases files upload-sourcemaps?
It is very strange that SENTRY_PROJECT env variable should be declared and there is no option to specify project in command.

Same here. Very weird on two fronts. It's been 8 months and no fix came out for a reasonably simple bug. And also docs don't mention this. Sad.

So the problem is not due to having more than one project released? My CircleCI config has the following line sentry-cli releases new -p node-server -p web-client $CIRCLE_SHA1.

Sentry is useless to me if I can't trace errors in an uglified file back to the source.

Same error message here, a SENTRY_PROJECT environment variable was dynamic exported at same stage, tested work with echo, but sentry cli says "project slug is required".

Temporary solution is write everything include token and project name in a .sentryclirc and delete it after source map uploaded

@Meeeeow
Works fine for me with env variables.

  variables:
    SENTRY_URL: https://selfhosted/
    SENTRY_ORG: org
    SENTRY_AUTH_TOKEN: SECRET
    SENTRY_PROJECT: projectname
  script:
    - cd app
    - npm install --loglevel warn
    - npm run build
    - mv dist/config.js.example dist/config.js
    - HASH=`git log --pretty="%h" -n1 HEAD`
    - VERSION=$CI_COMMIT_REF_NAME.$HASH
    - sed -i -e "s,%APP_VERSION%,$VERSION,g" dist/config.js
    # create release in sentry
    - sentry-cli releases new -p $SENTRY_PROJECT $VERSION
    - sentry-cli releases set-commits --auto $VERSION
    - sentry-cli releases files $VERSION upload-sourcemaps dist

@rtyshyk In my case, SENTRY_PROJECT was dynamic exported by a executable in script section, not defined in CI configuration.

Related to/Duplicate of https://github.com/getsentry/sentry-cli/issues/179
Let's track flags related issues there.

Just run into this. It's very odd that you need to define a project name when creating releases, but cannot pass one on cli options when uploading sourcemaps... Neither the cli help nor the docs mention this!

For anyone else that comes along. This combination works:

  • export SENTRY_PROJECT=yourproject
  • export SENTRY_AUTH_TOKEN=authtoken
  • sentry-cli releases -o your-organization new 1.4.0 --finalize
  • sentry-cli releases -o your-organization files 1.4.0 upload-sourcemaps -x map ./dist/js

What is still fuzzy to me is whether the version (1.4.0 in this case) needs to be unique across the org. Docs are unclear about this and given that you have to specify SENTRY_PROJECT I would assume that is obsolete. Can anybody confirm?

It's very odd that you need to define a project name when creating releases, but cannot pass one on cli options when uploading sourcemaps...

You can pass it with -p or --project flag:

sentry-cli releases -p your-project -o your-organization files 1.4.0 upload-sourcemaps -x map ./dist/js

What is still fuzzy to me is whether the version (1.4.0 in this case) needs to be unique across the org. Docs are unclear about this and given that you have to specify SENTRY_PROJECT I would assume that is obsolete. Can anybody confirm?

Releases are scoped per organization, so they need to be unique across the whole organization. We recommend prefixing your releases with the <project name>@<version>

Was this page helpful?
0 / 5 - 0 ratings