Versions Compared

Version Old Version 6 New Version 7
Changes made by

John McKeever

John McKeever

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Each Compliance rule can be augmented with additional rule metadata through the use of Attributes and Tags, each of which is described here.

Rule

...

Here’s an example of a rule definition.

Code Block
# Rule attributes
package datamigrators

# Rule tags (effectively user-defined, free-form attributes)
@Tag(“security, portability, maintainability, fail-ci, CorpDataWarehouse, CheeseSandwichTeam”)

# 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. The one attribute of interest to end users is @AssetType. This defines the type of DataStage asset to which the rule can be applied. All rules (whether those developed by customers or supplied by Data Migrators) require an @AssetType tag.

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.

Rule Tags

Each MettleCI Compliance rule can include extra metadata using a set of user-specified values which are referred to as ‘tags’. Each Compliance rule may specify zero or more ‘tags’ which are free-form text labels associated with each rule.

...

  • Tags are case insensitive.

  • We strongly recommend that the values your use for Tags employ only alphanumeric characters (0-9, a-Z, A-Z) as we can’t guarantee the support for non-alphanumeric tags across all potential platforms and use cases.

  • The default behaviour of not specifying any ‘Include’ tags is that everything is included.

  • The default behaviour of not specifying any ‘Exclude’ tags is that nothing is excluded.

  • When no ‘Include’ and ‘Exclude’ tags are specified Compliance Rules are not scanned recursively (existing behaviour).  When at least one tag is specified (either Include or Exclude), rules are scanned recursively.

  • You can use * to match all tags so you can use * to include everything and leave Exclude tags blank. This will trigger recursive scanning of rules (different from leaving both blank which results in the existing, shallow, non-recursive behaviour).

Rule Attributes

Here’s an example of a rule definition which incorporates some Tags.

Code Block
# Rule attributes
package datamigrators

# Rule tags (effectively user-defined, free-form attributes)
@Tag(“security, portability, maintainability, fail-ci, CorpDataWarehouse, CheeseSandwichTeam”)

# 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

...

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.

...