Skip to main content

Policy Actions

Policy actions allow you to designate an action to take when violations occur at a particular stage in the development lifecycle. For each stage, you can assign one of the following actions:

  • No Action - This is the default setting.

  • Warn - Policy violations are worthy of a warning.

  • Fail - Policy violations are severe enough to potentially halt the development lifecycle.

If Sonatype Lifecycle is integrated with a third-party external tool, the action selected can have a direct effect on the tool. When an external tool requests a policy evaluation (of an application, repository, or component), IQ Server provides policy violation information along with the action, which the tool may (or may not) implement. For example, if you set the Build stage to Fail in a policy, a CI tool (such as Bamboo, Jenkins, or Hudson) may stop the build of an application when that policy is violated. Similarly, in a different tool, if you set a stage to Warn, a warning message may be displayed or logged in a file when policy violations occur. For more details on using actions, see Usage Suggestions for Each Stage.

To add actions to a policy:

  1. In the Organization & Policy area, create a new policy or open an existing one for repositories or an organization or application.

  2. In the Policy editor, click the Actions button to scroll to the Actions section.

  3. Click the desired action — No Action, Warn, or Fail —at specific stage(s). In case of repositories, actions can be set only for the Proxy stage.

  4. Click Update (or Create) to save the policy.

Actions at root organization or organization or application level


Actions at Repositories level


Usage Suggestions for Each Stage

Sonatype provides various tools and plugins to enable policy evaluation during each stage of development lifecycle:

  • CLI

  • Maven plugin

  • Sonatype Repository Firewall

  • IDE plugins

  • CI plugins


Usage Suggestion


  • Available for the Sonatype Repository Firewall solution

  • Refers to proxy repositories where components enter your binary repository

  • Use the 'fail' action to quarantine components for quality review before being automatically downloaded by developers


  • Intended for evaluations from the development environments such as in the IDE

  • Used for evaluations that happen in Source Control Managers


  • Intended for scans in the source control repository

  • Scans on the default branch will use this stage

  • Pull Requests scan results are only reported as comments on that pull request


  • Use in ad-hoc scans or Continuous Integration workflows

  • The 'warn' action will flag a CI build as unstable

  • Only use 'fail' to halt builds when critical violations are discovered

Stage Release

  • Used with Lifecycle plugins for user acceptance testing (UAT) before the release phase

  • The 'warn' action is recommend

  • Use 'fail' when applications do not meet quality requirements


  • A last line of defense to protect production environments from non-compliant risk

  • The 'warn' action will flag a CI build as unstable

  • Use 'fail' to halt deployments when critical violations are discovered

  • Configure continuous monitoring on this stage to discover risk after after deploying to production


  • For integrations with deployment tools (e.g udeploy) or script

  • Evaluations at this stage will not show up in the dashboard or reporting views