generate

Flyway Migrations Generate Action

A GitHub Action that turns schema model edits into Flyway migration scripts and (by default) commits them back to the pull request that introduced the change.

The intended workflow is:

1. A developer edits the schema model in their feature branch and opens a pull request.
2. This action runs on the PR, compares the updated schema model against a build environment, and generates the migration scripts that would apply those changes.
3. The generated migrations are committed onto the PR branch, so reviewers see and review the SQL alongside the schema model changes — no need for the author to write migrations by hand.

Behavior

Runs flyway diff followed by flyway generate to produce migration scripts capturing the differences between your source (default schemaModel) and the build database. The migration types (e.g. versioned, undo, repeatable) default to whatever is configured in your flyway.toml.

This action requires Flyway Enterprise edition.

Prerequisites

This action requires Flyway to be installed. Use red-gate/setup-flyway@v3 before this action:

- uses: red-gate/setup-flyway@v3
  with:
    edition: enterprise
    i-agree-to-the-eula: true
    email: ${{ secrets.REDGATE_EMAIL }}
    token: ${{ secrets.REDGATE_TOKEN }}
- uses: red-gate/flyway-actions/migrations/generate@v2
  with:
    build-url: jdbc:postgresql://localhost/build

Usage

By default the action stages, commits, and pushes the generated files back to the branch the workflow ran on. Set commit-migrations: false to opt out. Authentication uses the credentials persisted by actions/checkout, so:

• the job needs permissions: contents: write
• actions/checkout must run first with its default persist-credentials: true
• on pull_request events, pass ref: ${{ github.head_ref }} to actions/checkout (as shown in the example below) so commits land on the PR branch rather than the detached merge commit
• if you need the push to re-trigger CI on the PR, check out with a PAT or app token (GITHUB_TOKEN pushes do not re-trigger workflows)
• pushes from forked PRs are not possible; this workflow is only useful for same-repo PRs

name: Generate Flyway migrations

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  generate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.head_ref }}
      - uses: red-gate/setup-flyway@v3
        with:
          edition: enterprise
          i-agree-to-the-eula: true
          email: ${{ secrets.REDGATE_EMAIL }}
          token: ${{ secrets.REDGATE_TOKEN }}
      - uses: red-gate/flyway-actions/migrations/generate@v2
        with:
          build-environment: build
          build-user: ${{ secrets.DB_USER }}
          build-password: ${{ secrets.DB_PASSWORD }}
          working-directory: my-flyway-project
          migration-description: add_orders_table

Iterating on the schema model after a migration is generated

Each run of the action diffs the current schema model against the migrations already in the branch and generates a new migration for whatever's still missing. If you push another schema model change after the action has already committed a migration, you'll end up with two migration scripts on the PR — one per push. To keep the PR to a single migration, before pushing your follow-up schema change either:

• drop the previous auto-generated commit via an interactive rebase (git rebase -i <base> and remove the auto-commit's line, then force-push), or
• delete the previously generated migration file from the branch and commit that deletion alongside your schema model change.

The next run will then regenerate a single combined migration covering all schema model edits.

Inputs

Input	Description	Required	Default
source	Source for the diff	No	schemaModel
migration-types	Comma-separated migration types to generate (e.g. versioned,undo). Defaults to reading the TOML	No
migration-description	Description used in the generated migration filename	No
build-environment	Build database environment used as the diff target	No
build-url	JDBC URL for the build database	No
build-user	Database user for the build database	No
build-password	Database password for the build database	No
build-schemas	Comma-separated list of schemas for the build database	No
working-directory	Working directory for Flyway	No
extra-args	Additional Flyway CLI arguments	No
commit-migrations	Commit and push the generated migrations	No	true
commit-message	Commit message used when commit-migrations is enabled	No	Generate Flyway migrations
commit-user-name	Git user.name used when commit-migrations is enabled	No	github-actions[bot]
commit-user-email	Git user.email used when commit-migrations is enabled	No	41898282+github-actions[bot]@users.noreply.github.com
commit-branch	Branch to push the commit to. Defaults to the PR head branch (GITHUB_HEAD_REF) on pull_request events, otherwise the current branch (GITHUB_REF_NAME)	No

If you do not pass any build-* inputs, the build environment is taken from your flyway.toml.

Outputs

Output	Description
exit-code	Flyway exit code
script-paths	JSON array of paths to the generated migration files
committed	true if the generated migrations were committed and pushed

The summary written to $GITHUB_STEP_SUMMARY lists each generated script, a table of the changes it captures (object name, object type, difference type), and any per-script warnings emitted by Flyway.

Using Outputs

- id: generate
  uses: red-gate/flyway-actions/migrations/generate@v2
  with:
    build-environment: build

- run: echo "Generated ${{ fromJson(steps.generate.outputs.script-paths)[0] }}"

Secrets

Store database credentials and license tokens in GitHub Actions secrets rather than hardcoding them in workflow files.

License

MIT