A tagger's lifecycle

Each tagger and its versions have a lifecycle that includes the following steps:

1. Create

The tagger is created with a unique name and an optional description. Newly created taggers are disabled by default and cannot be enabled until a tagger version is created, published, and successfully tested.

2. Draft

A new tagger version with corresponding tagger definition may be drafted and saved before being published. The latest published version is used as a starting point for new drafts when creating a draft in the web UI.

3. Publish

The last step to preparing a tagger version for invocation is to publish/finalize it. Once published, a tagger version's YAML definition is immutable and may not be edited. A new draft version must be created if you wish to make changes to the YAML definition.

4. Test

Test invocations are used to verify that the tagger works as expected before it may be applied to a large number of robologs.

Here are rules enforced by our platform that pertain to a tagger version's test status:

• You must successfully test a tagger version before it may be used for any other types of invocation.
• Requests for kicking off a backfill invocation of an untested tagger version will fail.
• A tagger cannot be enabled if a successfull tested tagger version does not exist for that tagger.
• Normfill invocations of an enabled tagger kicked off for each newly ingested robolog use the latest, successfully tested tagger version available—not necessarily the latest published version.

5. Enable

Enabling a tagger allows normfill invocations to automatically run for each new robolog that is ingested.

6. Edit

As you work with a tagger, you may find that you need to make changes to its definition. This process involves creating a new draft version, making the necessary changes, publishing, and testing the new version.

7. Backfill

A backfill allows you to run the tagger against robologs that have previously been ingested. Backfills must be manually initiated.