Automated Checks
  • 05 Jan 2023
  • 1 Minute to read
  • Dark
    Light
  • PDF

Automated Checks

  • Dark
    Light
  • PDF

Article Summary

You can define automatic checks that must be met before a build may be deployed to a stage. These are an extensible feature, and there are several built into BuildMaster.

Extensible FeatureDescription
Command LineExecutes a program via command line on the BuildMaster server.
File in ArtifactVerifies that a file exists in an Artifact before a promotion to the pipeline stage.
Issues ClosedVerifies that all issues are closed before a promotion to the pipeline stage.
Issues in StatusVerifies that issues are in a certain status before a promotion to the pipeline stage.
Pipeline Stage CompleteEnsures a pipeline stage of another application has been completed.
Change Controls PerformedVerifies that change controls have been performed.
Change Scripts RunVerifies that all required change scripts have been run successfully.
United Tests PassedVerifies that unit tests have passed in the last execution.
VariableEnsures a specified variable value before promotion to the pipeline stage.
Drift StatusVerifies that a specified Otter server or role is in a specified drift status.

These automatic approvals are verified periodically because they can change over time.

For example, if you've configured an Issues Closed automatic approval to verify that issues in a particular JIRA project are closed prior to promoting to a stage, BuildMaster won't be notified of a status change.

When an automatic approval is verified, the following information is recorded:

  • State (Met, Not Met, Not Required) - for example, if there are no issues associated with the release, the requirement would be Not Met, whereas the requirement would be Met only if all issues associated with the release were Resolved
  • Description - a text description of the approval conditions; for example, "3/8 issues are resolved"
  • Date/Time - a timestamp of when the approval was run

Was this article helpful?