By default, Flyway's check -code operation only functions on pending migrations, the rationale being that these are things you can still improve before deployment.

There are times when you want to be able to analyze all of the migrations, maybe this is part of a technical-debt assessment and investigating a running DB is difficult.

The way most people did this was to disconnect Flyway from it's database (for example by commenting out the URL parameter) - when Flyway can't read the schema history table it can't judge which migrations are pending and so would then run all the migrations it could find through the code analysis tools. This worked but it was a messy solution.

What we've done in Flyway 11.10.0 (2025-06-26) is to implement a new parameter, check.scope that allows you to manipulate what Flyway should consider for analysis.

As an example, if we have all our migrations already deployed:

./flyway info 
...
Database: jdbc:sqlite:dev.db (SQLite 3.41)
Schema version: 1

+-----------+---------+-------------+------+---------------------+---------+----------+
| Category  | Version | Description | Type | Installed On        | State   | Undoable |
+-----------+---------+-------------+------+---------------------+---------+----------+
| Versioned | 1       | first       | SQL  | 2025-07-16 15:43:41 | Success | No       |
+-----------+---------+-------------+------+---------------------+---------+----------+

Without changing anything

Here, Flyway will only look at pending migrations and there are none so 0 files are run through code analysis

./flyway check -code
...
Database: jdbc:sqlite:dev.db (SQLite 3.41)
SQLFluff code analysis summary:
Total analysis: 0 SQL file(s) scanned with dialect SQLITE applied
Files with violations: 0        Violations: 0

Configuring check.scope

Now Flyway will consider all the available migrations, whether or not they are pending (which is 1 migration).

These do still need to appear as files Flyway should concern itself with so need to conform to migration filename conventions. 

./flyway check -code -check.scope=all
...
Database: jdbc:sqlite::memory: (SQLite 3.41)
Schema history table "main"."flyway_schema_history" does not exist yet
SQLFluff code analysis summary:
Total analysis: 1 SQL file(s) scanned with dialect SQLITE applied
Files with violations: 1        Violations: 3

So we've seen how to expand the scope of what Flyway considers for performing code analysis on without having to modify the Flyway configuration