March 17 Johannes Schmitt schmittjoh

Introducing Build Failure Conditions

By default, Scrutinizer has no notion of whether the build for a specific commit failed or passed, it simply delegates that decision to your continuous integration service which after all runs your tests.

However, many people have voiced the desire to have builds fail based on certain conditions. For example, you might want to fail if a critical issue is introduced, a class has no tests, or the rating drops below a certain threshold, just to name a few uses cases.

We just rolled out a new DSL to make these checks possible. The DSL is super-easy to write and read, let’s take a look at a few examples:

# .scrutinizer.yml

build_failure_conditions:
    # No critical issue is present
    - 'issues.severity(= CRITICAL).exists'

    # No new critical issue is introduced (existing ones are tolerated)
    - 'issues.severity(= CRITICAL).new.exists'

    # Class has no tests
    - 'classes.metric("php_code_coverage.coverage", = 0).exists'

    # Rating is D or worse
    - 'elements.rating(<= D).exists'

You can read more about the options this DSL offers in our documentation. If your use-case is not yet covered, let us know.

If one of your failure conditions is true for an inspection, Scrutinizer will set the build to failed and add a prominent note to the summary page.

Inspection where failure condition was met

In case you are using GitHub, the build status will also be set through GitHub’s status API and merged with your continuous integration service.

Happy inspecting! :)

 

Have Feedback? Tweet to @scrutinizerci

If you experienced a bug or have any questions, please send them to [email protected].