Code goal analysis outside pull requests

Hi,
Is there a way to fail a CI task when there is critical issues in a specific branch or commit or tag?

What I want is to automate the check of security and issues in a deployment pipeline like I can do with sonar, because the analysis in pull requests is not enough it scans only in the context of that files changed. Suppose that we have ignored issues on pull request to release to a staging environment, when the pipeline to production runs, I want to make sure that this issues are revised and fail the deployment.

Deepsource provides analysis to a default branch, I could use that to check in the deployment pipeline. I would also like to configure the quality standard that is used to check, suppose we want 85% code coverage and no critical issues, and a max of 10 minor issues to pass the quality gate.

I’m not sure if this is a new feature or if there is ways to do that with the API.

Thanks.

1 Like

Hi @giovanni,

Is there a way to fail a CI task when there is critical issues in a specific branch or commit or tag?

Inside a repository’s setting, you can configure issue reporting and metric reporting i.e. you can choose to block PR checks for specific issue types and metrics. You can also set custom priorities to each issue and then configure which priority levels you want to block PR checks from the reporting tab in repository settings.

Suppose that we have ignored issues on pull request to release to a staging environment, when the pipeline to production runs, I want to make sure that this issues are revised and fail the deployment.

That is the behavior with DeepSource as well. You can suppress issue occurrences on a PR run to forcefully merge a PR but when the analysis then runs on the default branch for the merge commit, those issue occurrences will show up again marking that check as failed. Also, by default, DeepSource only analyzes the changeset in a PR but this is configurable from repository settings.

suppose we want 85% code coverage and no critical issues, and a max of 10 minor issues to pass the quality gate.

  • You can set thresholds for metrics like Line Coverage, Composite Coverage, etc from a repository’s metrics tab. Ref: Repository Metrics.
  • As I mentioned above, you can also set custom priorities to each issue that you deem critical and then configure for which priority levels you want to block PR checks from the reporting tab in repository settings.

I hope this was informative. Please let us know if you require further clarification!