Deployment tags

Deployment tags declare where a test suite is expected to run. Add them to every test.describe() (or apiTest.describe() / spaceTest.describe()), then use --grep when running tests to target a specific environment.

Tags follow this shape:

• @<location>-<arch>-<domain>

Where:

• location: local or cloud
• arch: stateful or serverless
• domain: classic, search, observability_complete, security_complete, …

Use the tags helper (see the full list below) to declare where your tests should run. By default, each helper expands to both @local-* and @cloud-* targets:

test.describe(
  'My suite',
  { tag: [...tags.stateful.classic, ...tags.serverless.security.complete] },
  () => {
    // ...
  }
);
		

This is equivalent to assigning all of these tags:

• @local-stateful-classic (local stateful)
• @cloud-stateful-classic (Elastic Cloud)
• @local-serverless-security_complete (local serverless)
• @cloud-serverless-security_complete (Elastic Cloud)

To restrict a test to local environments only, write the tag strings explicitly:

test.describe(
  'My suite',
  { tag: ['@local-stateful-classic', '@local-serverless-security_complete'] },
  () => {
    // ...
  }
);
		

This test will only run locally (stateful classic and serverless Security complete tier), and will be skipped by Elastic Cloud pipelines.

Pick the narrowest scope that's still correct for the feature under test, as every extra deployment target spins up an additional run:

Use this tag for platform specs that need to run across every standard deployment type. It expands to:

• tags.stateful.all
• tags.serverless.search
• tags.serverless.observability.complete
• tags.serverless.security.complete

VectorDB is excluded because it has no stateful counterpart.

This expands to @local-serverless-vectordb and @cloud-serverless-vectordb. VectorDB is included in tags.serverless.all, but not in tags.deploymentAgnostic (this project type doesn't have a stateful counterpart). Add its explicit tags when the test needs VectorDB coverage.

Use tags.performance for performance tests. It assigns the @perf tag.

For the authoritative list (and the exact tag strings), see src/platform/packages/shared/kbn-scout/src/playwright/tags.ts or just rely on editor autocomplete.

Limit tags filter tests by target attributes: properties of the environment a run executes in that the deployment target doesn't capture, such as Kibana running in FIPS mode. They are a separate concept from deployment tags and complement them rather than replace them: a suite still needs at least one deployment tag to be discovered at all.

Tags follow this shape:

• @limit/<only|except>-<attribute>

These are the available tags:

If a test would need more except tags than there are environments it actually applies to, it's an only test.

Add the limit tag next to the deployment tags:

test.describe(
  'FIPS-specific behavior',
  { tag: [...tags.deploymentAgnostic, tags.limit.only.fips] },
  () => {
    // ...
  }
);
		

A single test can carry a limit tag too, as long as the enclosing describe provides the deployment tags: test('...', { tag: [tags.limit.except.fips] }, async () => { ... }). Suites without a limit tag run regardless of attributes.

Scout rejects a suite that has only limit tags, or that combines only and except for the same attribute (it could never run).

1. Tag the suite with a limit tag.
2. Make sure the run declares its target attributes, so Scout can skip the suites whose limit tags don't apply. Scout never detects attributes on its own; with none declared, suites with a limit.only tag are skipped and suites with a limit.except tag run.

On CI, attributes are declared automatically from the build. Locally, pass them to scout run-tests with --targetAttribute (see Run tests).