...
Each Compliance rule may specify zero or more tag tags 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. How a rule’s breach should be indicated in Workbench or whether its use in a CI pipeline should produce an a 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)
...
| Code Block |
|---|
# Rule attributes package datamigrators # Rule tags (effectively user-defined, free-form attributes) @Tag(“security”"security") # This rule identifies a potential security vulnerability @Tag(“portability”"portability") # This rule identifies a issues with assets' portability between environments @Tag(“maintainability”"maintainability") # This rule identifies a potential maintainability issue @Tag(“CorpDataWarehouse”"CorpDataWarehouse") # This rule is specific to the 'CorpDataWarehouse' team @Tag(“fail"fail-ci”ci") # This rule is mandatory and so should fail continuous integration if breached # Rule definition <blah blah blah> |
Attributes are used to add extra information to the Rule which are used by the various MettleCI tools (Workbench, CLI) to change their behaviour.
| Info |
|---|
If you add a @Tag attribute to a rule you must also add a package value to the top of your Compliance rule. This is required by the technology underlying Compliance, and has no other functional implications. A good practice for the package name is to use a unique identifier which identifies the group assuming ownership (and responsibility for maintenance) of the rule. All out-of-the-box rules have a package name of ‘Data Migrators’, for example. |
Include and Exclude options for Compliance operations
...