Skip to main content

Azure DevOps

Scan every pull request from Azure Pipelines. Azure DevOps authenticates with a project-scoped CI key instead of OIDC.

Set it up​

  1. In Musha, open your project > Integration > Pull request scan.
  2. Click Create CI key. In CI keys, choose an expiry date and create the key. Copy it immediately: it is shown only once.
  3. In Azure DevOps, add the key as a secret variable named MUSHA_API_KEY (Pipeline > Edit > Variables).
  4. Copy the pipeline from the Integration guide into azure-pipelines.yml. It comes with your project ID filled in.
  5. Add the pipeline as a Build Validation branch policy (see below).

Run it on pull requests​

For Azure Repos, the pr: keyword in the YAML is silently ignored. To run the pipeline on pull requests:

  1. Go to Repos > Branches, open the menu of your default branch and choose Branch policies.
  2. Under Build Validation, add this pipeline.

The generated pipeline sets trigger: none so it does not also run on pushes.

What the pipeline does​

  • Fetches the full history (fetchDepth: 0) so the pull request diff can be computed.
  • Works out which lines the pull request added.
  • Packages the code, excluding .git and node_modules, and uploads it to Musha with your key.
  • Musha posts a comment on the pull request.

The key​

PropertyValue
ScopeOne project. It can create scans for that project and do nothing else
ExpiryRequired, one year at most
LimitFive active keys per project
FormatStarts with msk_live_
StorageAs a secret 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, make the Build Validation policy Required.

Troubleshooting​

The pipeline doesn't run on pull requests. The Build Validation policy is missing. See above.

401 or 403. The key is expired, revoked or belongs to another project. Create a new one in CI keys.

A 429 response. See Limits.