Bitbucket Pipelines
Scan every pull request from Bitbucket Pipelines. Bitbucket authenticates with a project-scoped CI key instead of OIDC.
Set it up
- In Musha, open your project > Integration > Pull request scan.
- Click Create CI key. In CI keys, choose an expiry date and create the key. Copy it immediately: it is shown only once.
- In Bitbucket, add it as a secured repository variable named
MUSHA_API_KEY(Repository settings > Repository variables). - Copy the pipeline from the Integration guide into
bitbucket-pipelines.yml. It comes with your project ID filled in.
What the pipeline does
- Runs under
pipelines: pull-requests, never on a bare push. - Clones the full history (
clone: depth: full) so the pull request diff can be computed. - Works out which lines the pull request added.
- Packages the code, excluding
.gitandnode_modules, and uploads it to Musha with your key. - Sends
BITBUCKET_PR_IDas the pull request number, which is what lets Musha post the comment.
The key
| Property | Value |
|---|---|
| Scope | One project. It can create scans for that project and do nothing else |
| Expiry | Required, one year at most |
| Limit | Five active keys per project |
| Format | Starts with msk_live_ |
| Storage | As a secured variable. Never in the repository |
To rotate: create a new key, update the variable, then revoke the old one in CI keys.
Failing the pipeline when a scan is blocked
The response of the upload says whether the scan was blocked ("blocked": true), but the generated step does not fail on it: the comment is posted and the pipeline stays green. To make the pipeline fail, save the response to a file and check it, as shown in GitLab CI. To stop the merge, require a successful build in your Bitbucket merge checks.
Troubleshooting
The pipeline doesn't run on pull requests. It must be defined under pipelines: pull-requests.
401 or 403. The key is expired, revoked or belongs to another project. Create a new one in CI keys.
No pull request comment. See Troubleshooting.
A 429 response. See Limits.