Set up GitHub Actions

This page explains setting up a GitHub Actions pipeline that uses a self-hosted runner to execute Liquibase operations through Liquibase flow files.

Prerequisites

An integration with GitHub Actions requires the following:

• A GitHub account with permission to administer the repository you created in your GitHub organization

• Liquibase Secure installed on a self-hosted GitHub Actions runner. The network must be configured from this runner to allow connections to the databases you wish to manage

Complete Set up the automation prerequisites first: the repository, the branches, and the three databases are shared with the Azure DevOps example.

For more on setting up GitHub Actions, see the GitHub Actions documentation.

1. Set up environments and secrets

Set up your environments in GitHub using Secure setup using GitHub Actions secrets.

The example uses DEV, QA, and PROD environments.

2. Execute the development pipeline

There are four GitHub Actions provided in the example repository, each of which executes under certain conditions:

Liquibase Secure CI Workflow executes whenever a pull request is opened against the develop branch. When it runs, it runs the pre-merge custom policy checks via Liquibase flow.

Liquibase Secure CD Workflow executes whenever a push event occurs on the develop branch. A push event can occur for several reasons, including merging a pull request, or a repository administrator bypassing rules and pushing directly to the branch. When it runs, it deploys all pending changes, including any that were previously rolled back.

Liquibase Secure Deployment Workflow performs ad hoc deployments. Select and run it manually from your repository's Actions tab.

Liquibase Secure Rollback One Update Workflow rolls back the previous deployment. Run it from your repository's Actions tab.

Why the CD workflow redeploys rolled-back changes

That detail in the CD workflow is worth pausing on, because it surprises people. Rolling back does not remove a changeset from your changelog, it removes it from the tracking table. The next deployment therefore sees it as pending and applies it again.

If you rolled back because a change was wrong, remove or fix the changeset before the next push to develop, or the pipeline will faithfully redeploy the thing you just undid. See Plan your rollback strategy.