Redgate Flyway

Flyway Tags Namespace

  • Status: Preview

Flyway Enterprise

This namespace contains the configuration options for migration tags.

Description

Migration scripts can be assigned one or more custom tags. Tags provides a convenient way to cherryPick and order groups of scripts together when used with other flyway commands such as info, migrate and undo through the use of tag conditions.

When using tag conditions to select which migration scripts are deployed or the order of the deployment, outOfOrder must be enabled.

If you prefer to select or control the order of individual migrations rather than sets of migrations, you can use cherryPick directly. Tag conditions and cherryPick cannot be used simultaneously.

If you want to run migrations up to a specific target version, you can use the target setting. Tag conditions and target cannot be used simultaneously.

Defining tags

Versioned migration scripts can be given tags by specifying tag definitions inside the project toml.

Example:

[flyway.tags.definitions]
"0.1" = ["tagA"]
"0.2" = ["tagB"]
"0.3" = ["tagC", "tagB"]

Repeatable migrations are not supported with tags at this time.

Selecting migrations for deployment using tag conditions

Migrations can be selected by tag for use with flyway commands such as migrate and undo using the anyOf, allOf and noneOf conditions. If more than one tag condition is specified, then migrations must match the criteria of all given conditions to be selected. In the case where no migrations match the given tag conditions, flyway will raise an error.

Example:

./flyway "-tags.anyOf=tagB" "-tags.noneOf=tagC" info

With the toml specified above this would return only migration 0.3 as pending from info, with 0.1 and 0.2 marked as ignored.

Controlling deployment order using tag conditions

Tags can be used to control the order migrations are run using the deployment order.

Example:

./flyway "-tags.deploymentOrder=tagB,tagA" info

With the toml specified above this would select migrations in the order 0.2, 0.3, 0.1, rather than the default behavior of running migrations in version order.


Didn't find what you were looking for?