...
Each Compliance rule can be augmented with additional rule metadata through the use of Attributes and Tags, each annotations, the most significant of which is the Tag annotation which is described here.
Rule
...
Annotations
Annotations add extra information to a Compliance rule for use by the MettleCI Workbench and CLI to change their behaviour. Annotations consist of a keyword starting with an @ character followed by relevant metadata. The only annotation you need to use on a day-to-day basis is the @tag annotation which, although optional, is strongly recommended.
| Info |
|---|
If you add a A good practice for the package name is to use a unique value which identifies the group that owns (and is responsible for maintaining) the rule. All out-of-the-box rules have a set of suggested tags and a package name of |
Rule Tags
Each Compliance rule may specify zero or more ‘tags’ tag which are free-form text labels associated with each rule. Rule Tagging provides improved rule metadata management in support of a number of use cases:
Identifying the ‘severity’ of each rule. The MettleCI tools that use Compliance results (the Workbench user interface and the mettleci compliance test CLI command) need to know how to respond to Compliance Rule breaches. Whether How a rule’s breach should produce an abort (Fail) or informational (Warning) be indicated in Workbench or whether its use in a CI pipeline is currently defined (somewhat awkwardly) by the folder within which the rule exists in the repository. For NextGen this metadata would be better defined using taggingshould produce an warning) message or abort the pipeline entirely can be defined using Tags.
Grouping Compliance Rules into ‘bundles’ of functionally related rules. This could enable users to report or test by functional area. Functional groups into which Compliance Rules could be bundled might be Performance, Security, Maintainability, etc. Tagging also permits a single rule to be associated with multiple functional areas, if required.
Enabling the fine-grained sharing of rules across teams within organisations (i.e. tags could be used to identify which DataStage teams they apply to)
Defining rules’ behaviour in different environments (e.g. Workbench vs. CI/CD plans)
...
The example CI/CD build pipelines that ship with MettleCI demonstrate the use of tags to identify which rules inhibit the successful completion of CI.
...
Using Tags
Here’s an example of a rule definition which incorporates some Tags.
...
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The Compliance Test mettleci compliance test command (available within the Compliance namespace of the MettleCI Command Line Interface) permits you to use provides -include-tag and -exclude-tag options to filter the rules which will are be used by the command. The way that MettleCI interprets these options means so that set of include tags is used first, then the set of exclude tags is removed. In the diagram above, only the rules with tags in set A and NOT in B will be used to select Compliance Rules (formally referred to as the 'relative complement of B in A'). Similarly, the MettleCI Workbench permits you to specify which include and exclude tags will be used when testing your Job’s Compliance interactively from within the Workbench interface.
...