Bump version to flyway-10.21.0

Please see the GH release for the release notes

Update H2 2.3.224 to 2.3.232

Improve repair performance

Upgrade snowflake-jdbc 3.14.3 to 3.20.0 to fix CVE-2024-43382

documentation/Flyway CLI and API/Commands/Auth.md

@@ -7,7 +7,7 @@ subtitle: Auth
 
 If `auth` is run on a machine that is connected to the internet with an accessible browser, Flyway will launch a web browser prompting the user to log in with their Redgate account
 username and password. Please note that `auth` is not supported on WSL, nor when using SSH. For these cases and any where a web browser is inaccessible on the same machine that is
-running Flyway, it is recommended to use an [offline mechanism](<Configuration/Flyway Licensing>) to license Flyway.
+running Flyway, it is recommended to use an [non-interactive mechanism](<Configuration/Flyway Licensing>) to license Flyway.
 
 Upon successful login, a license permit is then saved to disk in the `Flyway CLI` directory of the Redgate app data folder. If the user is offline, a
 [link to create a license permit](https://permits.red-gate.com/offline?productCode=63) will be printed to the console. The user can then copy the license permit

documentation/Flyway CLI and API/Commands/Repair.md

@@ -8,7 +8,7 @@ Repairs the schema history table.
 ![Repair](assets/command-repair.png)
 
 Repair is your tool to fix issues with the schema history table. It has a few main uses:
-- Remove failed migration entries (only for databases that do NOT support DDL transactions)
+- Remove failed migration entries
 - Realign the checksums, descriptions, and types of the applied migrations with the ones of the available migrations
 - Mark all missing migrations as **deleted**
     - As a result, `repair` must be given the same [`locations`](Configuration/parameters/flyway/locations) as `migrate`!

documentation/Flyway CLI and API/Concepts/Check Code concept.md

@@ -37,7 +37,7 @@ If you provide a URL/environment to `check -code` Flyway will use it to automati
 If no URL is provided, then you need to configure the dialect in a `.sqlfluff` configuration file.
 This file needs to be located in the same location as the migrations being analysed.
 
-You can find more information on configuration in the [SQLFLuff documentation](https://docs.sqlfluff.com/en/stable/configuration.html).
+You can find more information on configuration in the [SQLFLuff documentation](https://docs.sqlfluff.com/en/stable/configuration/default_configuration.html).
 
 ## Analysis engine: Regular Expressions
 {% include enterprise.html %}

documentation/Flyway CLI and API/Configuration/Parameters/Flyway/License Key.md

@@ -7,6 +7,8 @@ redirect_from: Configuration/licenseKey/
 # License Key
 {% include redgate.html %}
 
+This parameter is deprecated and will be removed in a future release.
+
 This is how legacy Flyway licensing is managed to enable features in Flyway.
 
 Flyway V10 brings online authentication - see [Flyway Auth](Commands/Auth)

documentation/Flyway CLI and API/Configuration/Provisioners/Backup Provisioner.md

@@ -39,3 +39,58 @@ backupVersion = "995"
 ```
 
 This example will restore the backup file located at `\\DBOps1\Backups\backup.bak` to the `MyDatabase` database in the shadow environment. The `MyDatabase` database will be at version 995. This example represents a common scenario where a user may wish to reset the shadow environment to the same state as production, so that new development migrations can then be applied to the shadow and verified.
+
+## SQL Server WITH MOVE
+
+The T-SQL "WITH MOVE" syntax makes it possible to specify the file paths on disk that data and log files should be
+restored to. This can be required in a couple of scenarios:
+
+- The directory structure on the target database doesn't match that of the source database. For example, the source
+  database stores data and log files under the `C:` drive, whilst the target database has no `C:` drive and stores
+  database files under the `D:` drive.
+- The data and log file paths embedded in the backup file are already being used by a different database. For example,
+  taking a database backup and restoring it on the same SQL Server instance but under a different database name, so
+  that the restored database exists alongside the original. In this scenario, new file paths to restore the data and log
+  files must be provided when performing the restore.
+
+The backup provisioner provides two methods for adjusting the data and log files paths when restoring a database.
+
+## Auto-generate data and log file paths
+
+The backup provisioner exposes a `generateWithMove` boolean parameter, which defaults to false. When set to true, the
+backup provisioner will auto-generate file paths for any data and log files contained within the backup file, and
+restore the backup using these generated file paths. The example toml below shows how this can be enabled:
+
+```toml
+[environments.shadow.resolvers.backup]
+backupFilePath = '/tmp/backup/backup.bak'
+backupVersion = "995"
+sqlserver.generateWithMove = true
+```
+
+## Specify data and log file paths
+
+An alternative to the `generateWithMove` parameter above is to specify the exact file path that data and log files
+should be restored to. The example toml below shows how this can be done:
+
+```toml
+[environments.shadow.resolvers.backup]
+backupFilePath = '/tmp/backup/backup.bak'
+backupVersion = "995"
+
+[[environments.shadow.resolvers.backup.sqlserver.files]]
+logicalName = "NewWorldDB"
+filePath = "/var/opt/mssql/data/NewWorldDB_shadow_data.mdf"
+
+[[environments.shadow.resolvers.backup.sqlserver.files]]
+logicalName = "NewWorldDB_log"
+filePath = "/var/opt/mssql/data/NewWorldDB_shadow_log.ldf"
+```
+
+Where:
+
+- `logicalName` is the logical name of a data or log file in the backup file.
+- `filePath` is the file path on disk where the logical file will be restored to.
+
+**Note**: When file paths are provided as above, then the `generateWithMove` parameter is ignored.
+i.e. User defined file paths take precedence over auto-generated file paths.

documentation/Flyway CLI and API/Configuration/Secrets Management.md

@@ -5,7 +5,7 @@ redirect_from: /documentation/awsSecretsManager/
 # Secrets Management
 {% include enterprise.html %}
 
-A problem that organizations often encounter is where to store and how to access sensitive data such as the credentials for connecting to a database or their Flyway license key.
+A problem that organizations often encounter is where to store and how to access sensitive data such as the credentials for connecting to a database.
 
 Flyway comes with support for the following secrets management solutions that enable you to successfully handle sensitive data:
 
@@ -62,7 +62,7 @@ Now you can run `migrate`, `info`, etc. and the credentials will be pulled out o
 
 ## Dapr Secret Store
 
-Flyway integrates with [Dapr's](https://docs.dapr.io/developing-applications/building-blocks/secrets/secrets-overview/) Secret Store in order to allow users to store Flyway configuration parameters securely. This can be used to securely read license keys without storing them in application configuration, and other configuration parameters can also be stored and read such as your database password or Flyway placeholders.
+Flyway integrates with [Dapr's](https://docs.dapr.io/developing-applications/building-blocks/secrets/secrets-overview/) Secret Store in order to allow users to store Flyway configuration parameters securely. This can be used to securely read license tokens without storing them in application configuration, and other configuration parameters can also be stored and read such as your database password or Flyway placeholders.
 
 Parameters stored in secrets in Dapr are read with the highest priority and will override all other configurations.
 
@@ -80,7 +80,7 @@ After configuring the above parameters, we would be able to connect to a databas
 
 ## Google Cloud Secret Manager
 
-Flyway integrates with [Google Cloud Secret Manager](https://cloud.google.com/secret-manager/) (GCSM) in order to allow users to store Flyway configuration parameters securely. This can be used to securely read license keys without storing them in application configuration, and other configuration parameters can also be stored and read such as your database password or Flyway placeholders.
+Flyway integrates with [Google Cloud Secret Manager](https://cloud.google.com/secret-manager/) (GCSM) in order to allow users to store Flyway configuration parameters securely. This can be used to securely read license tokens without storing them in application configuration, and other configuration parameters can also be stored and read such as your database password or Flyway placeholders.
 
 Parameters stored in secrets in GCSM are read with the highest priority and will override all other configurations.
 
@@ -98,7 +98,7 @@ After configuring the above parameters, we would be able to connect to a databas
 
 ## HashiCorp Vault
 
-Flyway integrates with [Vault's](https://www.vaultproject.io/) key-value engine in order to allow users to store Flyway configuration parameters securely. This can be used to securely read license keys without storing them in application configuration, and other configuration parameters can also be stored and read such as your database password or Flyway placeholders.
+Flyway integrates with [Vault's](https://www.vaultproject.io/) key-value engine in order to allow users to store Flyway configuration parameters securely. This can be used to securely read license tokens without storing them in application configuration, and other configuration parameters can also be stored and read such as your database password or Flyway placeholders.
 
 Parameters stored in secrets in Vault are read with the highest priority and will override all other configurations.
 

documentation/Flyway CLI and API/Tutorials/Tutorial - Using Flyway Check with SQL Server.md

@@ -41,7 +41,6 @@ Our `flyway.conf` file (found in the `conf` folder), should contain the followin
 flyway.url=jdbc:sqlserver://localhost;databaseName=foobar;trustServerCertificate=true
 flyway.user=sa
 flyway.password=Flyway123
-flyway.licenseKey=<put your license key here>
 
 flyway.check.buildUrl=jdbc:sqlserver://localhost;databaseName=check_build_db;trustServerCertificate=true
 flyway.reportFilename=check_report
@@ -135,7 +134,6 @@ Inside `conf`, place a file called `flyway.conf` and add the following contents:
 flyway.url=jdbc:sqlserver://localhost;databaseName=foobar;trustServerCertificate=true
 flyway.user=sa
 flyway.password=Flyway123
-flyway.licenseKey=<put your license key here>
 
 flyway.check.buildUrl=jdbc:sqlserver://localhost;databaseName=check_build_db;trustServerCertificate=true
 flyway.reportFilename=reports/check_report
@@ -164,7 +162,8 @@ services:
     image: redgate/flyway
     command: -url=jdbc:sqlserver://db;trustServerCertificate=true -check.buildUrl=jdbc:sqlserver://db;databaseName=check_build_db;trustServerCertificate=true -password=Flyway123 -user=sa -reportFilename=reports/check_report check -changes
     environment:
-      - FLYWAY_LICENSE_KEY=<put your license key here>
+      - FLYWAY_EMAIL=<put your PAT email here>
+      - FLYWAY_TOKEN=<put your PAT here>
     volumes:
       - ./sql:/flyway/sql
       - ./reports:/flyway/reports

documentation/Flyway CLI and API/Usage/Command-line/Command-line - repair.md

@@ -5,7 +5,7 @@ subtitle: 'Command-line: repair'
 # Command-line: repair
 
 Repairs the Flyway schema history table. This will perform the following actions:
-- Remove any failed migrations on databases without DDL transactions<br/>
+- Remove any failed migrations<br/>
             (User objects left behind must still be cleaned up manually)
 - Realign the checksums, descriptions and types of the applied migrations with the ones of the available migrations
 - Mark all missing migrations as **deleted**
@@ -21,37 +21,6 @@ Repairs the Flyway schema history table. This will perform the following actions
 
 See [configuration](Configuration/parameters) for a full list of supported configuration parameters.
 
-## Sample configuration
-
-```properties
-flyway.driver=org.hsqldb.jdbcDriver
-flyway.url=jdbc:hsqldb:file:/db/flyway_sample
-flyway.user=SA
-flyway.password=mySecretPwd
-flyway.connectRetries=10
-flyway.initSql=SET ROLE 'myuser'
-flyway.schemas=schema1,schema2,schema3
-flyway.table=schema_history
-flyway.locations=classpath:com.mycomp.migration,database/migrations,filesystem:/sql-migrations,s3:migrationsBucket,gcs:migrationsBucket
-flyway.sqlMigrationPrefix=Migration-
-flyway.undoSqlMigrationPrefix=downgrade
-flyway.repeatableSqlMigrationPrefix=RRR
-flyway.sqlMigrationSeparator=__
-flyway.sqlMigrationSuffixes=.sql,.pkg,.pkb
-flyway.encoding=ISO-8859-1
-flyway.placeholderReplacement=true
-flyway.placeholders.aplaceholder=value
-flyway.placeholders.otherplaceholder=value123
-flyway.placeholderPrefix=#[
-flyway.placeholderSuffix=]
-flyway.resolvers=com.mycomp.project.CustomResolver,com.mycomp.project.AnotherResolver
-flyway.skipDefaultResolvers=false
-flyway.callbacks=com.mycomp.project.CustomCallback,com.mycomp.project.AnotherCallback
-flyway.skipDefaultCallbacks=false
-flyway.workingDirectory=C:/myProject
-flyway.jdbcProperties.myProperty=value
-```
-
 ## Sample output
 
 <pre class="console">&gt; flyway repair

documentation/Flyway CLI and API/Usage/Gradle Task/Gradle Task - flywayRepair.md

@@ -5,7 +5,7 @@ subtitle: 'gradle flywayRepair'
 # Gradle Task: flywayRepair
 
 Repairs the Flyway schema history table. This will perform the following actions:
-- Remove any failed migrations on databases without DDL transactions<br/>
+- Remove any failed migrations<br/>
   (User objects left behind must still be cleaned up manually)
 - Realign the checksums, descriptions and types of the applied migrations with the ones of the available migrations
 
@@ -19,44 +19,6 @@ Repairs the Flyway schema history table. This will perform the following actions
 
 See [configuration](Configuration/parameters) for a full list of supported configuration parameters.
 
-## Sample configuration
-
-```groovy
-flyway {
-    driver = 'org.hsqldb.jdbcDriver'
-    url = 'jdbc:hsqldb:file:/db/flyway_sample;shutdown=true'
-    user = 'SA'
-    password = 'mySecretPwd'
-    connectRetries = 10
-    initSql = 'SET ROLE \'myuser\''
-    schemas = ['schema1', 'schema2', 'schema3']
-    table = 'schema_history'
-    locations = ['classpath:migrations1', 'migrations2', 'filesystem:/sql-migrations', 's3:migrationsBucket', 'gcs:migrationsBucket']
-    sqlMigrationPrefix = 'Migration-'
-    undoSqlMigrationPrefix = 'downgrade'
-    repeatableSqlMigrationPrefix = 'RRR'
-    sqlMigrationSeparator = '__'
-    sqlMigrationSuffixes = ['.sql', '.pkg', '.pkb']
-    encoding = 'ISO-8859-1'
-    placeholderReplacement = true
-    placeholders = [
-        'aplaceholder' : 'value',
-        'otherplaceholder' : 'value123'
-    ]
-    placeholderPrefix = '#['
-    placeholderSuffix = ']'
-    resolvers = ['com.mycompany.proj.CustomResolver', 'com.mycompany.proj.AnotherResolver']
-    skipDefaultResolvers = false
-    callbacks = ['com.mycompany.proj.CustomCallback', 'com.mycompany.proj.AnotherCallback']
-    skipDefaultCallbacks = false
-    workingDirectory = 'C:/myproject'
-    jdbcProperties = [
-      'someProperty' : 'someValue',
-      'someOtherProperty' : 'someOtherValue'
-    ]
-}
-```
-
 ## Sample output
 
 <pre class="console">&gt; gradle flywayRepair -i

documentation/Flyway CLI and API/Usage/Maven Goal/Maven Goal - Repair.md

@@ -5,7 +5,7 @@ subtitle: 'mvn flyway:repair'
 # Maven Goal: Repair
 
 Repairs the Flyway schema history table. This will perform the following actions:
-- Remove any failed migrations on databases without DDL transactions<br/>
+- Remove any failed migrations<br/>
   (User objects left behind must still be cleaned up manually)
 - Realign the checksums, descriptions and types of the applied migrations with the ones of the available migrations
 
@@ -19,67 +19,6 @@ Repairs the Flyway schema history table. This will perform the following actions
 
 See [configuration](Configuration/parameters) for a full list of supported configuration parameters.
 
-## Sample configuration
-
-```xml
-<configuration>
-    <driver>org.hsqldb.jdbcDriver</driver>
-    <url>jdbc:hsqldb:file:${project.build.directory}/db/flyway_sample;shutdown=true</url>
-    <user>SA</user>
-    <password>mySecretPwd</password>
-    <connectRetries>10</connectRetries>
-    <initSql>SET ROLE 'myuser'</initSql>
-    <schemas>
-        <schema>schema1</schema>
-        <schema>schema2</schema>
-        <schema>schema3</schema>
-    </schemas>
-    <table>schema_history</table>
-    <locations>
-        <location>classpath:migrations1</location>
-        <location>migrations2</location>
-        <location>filesystem:/sql-migrations</location>
-    </locations>
-    <sqlMigrationPrefix>Migration-</sqlMigrationPrefix>
-    <undoSqlMigrationPrefix>downgrade</undoSqlMigrationPrefix>
-    <repeatableSqlMigrationPrefix>RRR</repeatableSqlMigrationPrefix>
-    <sqlMigrationSeparator>__</sqlMigrationSeparator>
-    <sqlMigrationSuffixes>
-        <sqlMigrationSuffix>.sql</sqlMigrationSuffix>
-        <sqlMigrationSuffix>.pkg</sqlMigrationSuffix>
-        <sqlMigrationSuffix>.pkb</sqlMigrationSuffix>
-    </sqlMigrationSuffixes>
-    <encoding>ISO-8859-1</encoding>
-    <placeholderReplacement>true</placeholderReplacement>
-    <placeholders>
-        <aplaceholder>value</aplaceholder>
-        <otherplaceholder>value123</otherplaceholder>
-    </placeholders>
-    <placeholderPrefix>#[</placeholderPrefix>
-    <placeholderSuffix>]</placeholderSuffix>
-    <resolvers>
-        <resolver>com.mycompany.project.CustomResolver</resolver>
-        <resolver>com.mycompany.project.AnotherResolver</resolver>
-    </resolvers>
-    <skipDefaultResolvers>false</skipDefaultResolvers>
-    <callbacks>
-        <callback>com.mycompany.project.CustomCallback</callback>
-        <callback>com.mycompany.project.AnotherCallback</callback>
-    </callbacks>
-    <skipDefaultCallbacks>false</skipDefaultCallbacks>
-    <skip>false</skip>
-    <configFiles>
-        <configFile>myConfig.conf</configFile>
-        <configFile>other.conf</configFile>
-    </configFiles>
-    <workingDirectory>/my/working/dir</workingDirectory>
-    <jdbcProperties>
-      <myProperty>myValue</myProperty>
-      <myOtherProperty>myOtherValue</myOtherProperty>
-    </jdbcProperties>
-</configuration>
-```
-
 ## Sample output
 
 <pre class="console">&gt; mvn flyway:repair

documentation/Release notes and older versions/Release Notes for Flyway Engine.html

@@ -9,6 +9,38 @@
 <div class="col-md-9">
 
   <div class="release">
+        <h2 id="10.21.0">Flyway 10.21.0 (2024-11-07)</h2>
+
+        <h3>Breaking changes</h3>
+        <ul>
+            <li>Removed`check.url`, `check.password` and `check.username`. These undocumented historic fields have been deprecated for a while and have confusing impacts (such as not working in all check functionality). It is recommended to use environments to replace this functionality, alternatively, check does support standard `url`, `username` and `password`</li>
+        </ul>
+
+        <h3>Bug fixes</h3>
+        <ul>
+            <li>Fixed an issue that the Repair command was unable to remove failed Repeatable migration entries in schema history table for MongoDB</li>
+        </ul>
+
+        <h3>Changes</h3>
+        <ul>
+            <li>Backup provisioner now puts database into single user mode before restoring</li>
+            <li>Legacy Flyway keys (FL0...) are now deprecated</li>
+        </ul>
+
+        <h3>Java compatibility</h3>
+        <ul>
+            <li>Update H2 2.3.224 to 2.3.232</li>
+            <li>Upgrade snowflake-jdbc 3.14.3 to 3.20.0 to fix CVE-2024-43382</li>
+        </ul>
+
+        <h3>Performance improvements</h3>
+        <ul>
+            <li>Improved `repair` performance when removing failed migrations</li>
+        </ul>
+
+    </div>
+
+<div class="release">
         <h2 id="10.20.1">Flyway 10.20.1 (2024-10-24)</h2>
 
         <h3>Bug fixes</h3>

documentation/_config.yml

@@ -1,4 +1,4 @@
-flywayVersion: 10.20.1
+flywayVersion: 10.21.0
 enterpriseUrl: https://download.red-gate.com/maven/release/com/redgate/flyway
 kramdown:
   smart_quotes: ["apos", "apos", "quot", "quot"]