Liquibase Runner - Jenkins Declarative Pipeline

I’m trying to run Liquibase update in a Jenkins Declarative Pipeline.

image

Tried to way to execute update

First Attempt used this method
steps {
liquibaseUpdate (
changeLogFile:’./src/main/resources/dbchangelog/DEPLOY_INT_UTILITY-msdb_DB.xml’,
liquibasePropertiesPath:’./src/main/resources/liquibase.properties’
)
}

Second attempt use this method

steps {
liquibaseUpdate {
changeLogFile(’./src/main/resources/dbchangelog/DEPLOY_INT_UTILITY-msdb_DB.xml’)
liquibasePropertiesPath(’./src/main/resources/liquibase.properties’)
}
}
Error Message
[Checks API] No suitable checks publisher found.
java.lang.NoSuchMethodError: No such DSL method ‘liquibaseUpdate’ found among steps [ArtifactoryGradleBuild, MavenDescriptorStep, addInteractivePromotion, ansiColor, archive, artifactoryBuildTrigger, artifactoryDistributeBuild, artifactoryDownload, artifactoryEditProps, artifactoryGoPublish, artifactoryGoRun, artifactoryMavenBuild, artifactoryNpmInstall, artifactoryNpmPublish, artifactoryNugetRun, artifactoryPipRun, artifactoryPromoteBuild, artifactoryUpload, bat, build, catchError, checkout, collectEnv, collectIssues, compareVersions, conanAddRemote, conanAddUser, deleteDir, deployArtifacts, dir, dockerFingerprintFrom, dockerFingerprintRun, dockerPullStep, dockerPushStep, echo, emailext, emailextrecipients, envVarsForTool, error, fileExists, findBuildScans, findFiles, getArtifactoryServer, getContext, getLastChangesPublisher, git, githubNotify, httpRequest, initConanClient, input, isUnix, jfPipelines, jiraComment, jiraIssueSelector, jiraSearch, junit, library, libraryResource, load, lock, mail, milestone, newArtifactoryServer, newBuildInfo, newGoBuild, newGradleBuild, newMavenBuild, newNpmBuild, newNugetBuild, newPipBuild, nexusPolicyEvaluation, nexusPublisher, node, nodesByLabel, office365ConnectorSend, parallel, powershell, properties, publishBuildInfo, publishChecks, publishHTML, publishLastChanges, pwd, pwsh, readCSV, readFile, readJSON, readManifest, readMavenPom, readProperties, readTrusted, readYaml, resolveScm, retry, rtAddInteractivePromotion, rtBuildInfo, rtBuildTrigger, rtCollectIssues, rtConanClient, rtConanRemote, rtConanRun, rtDeleteProps, rtDockerPush, rtDotnetResolver, rtDotnetRun, rtDownload, rtGoDeployer,

Hi @bilal.bailey!

I am not a declarative pipeline expert but, the only difference I can see between your pipeline code and this example is the user is making the liquibase calls from a stage, not a step:

node {
   stage('Checkout') {
      git url: 'https://github.com/piomin/sample-liquibase-maven.git', credentialsId: 'piomin_gitlab', branch: 'master'
   }

   stage('Update') {
      liquibaseUpdate changeLogFile: 'src/main/script/changelog-master.xml', url: 'jdbc:mysql://192.168.99.100:33306/default?useSSL=false', credentialsId: 'mysql_default', databaseEngine: 'MySQL'
   }
}

Would love others to weigh in that know more around the calling of liquibase from jenkins declarative (groovy?) pipeline.

@ronak in a declarative pipeline step Jenkins requires the steps{} to be included inside stage{}

What I’ve noticed that I find to be peculiar is that I can’t find Liquibase in the Pipeline Syntax generator?

Hey @bilal.bailey,

I’m not sure why Pipeline Syntax generator doesn’t have the Liquibase syntax and don’t have a jenkins setup at the moment.

As a workaround, till someone in the community (:crossed_fingers:) can weigh in, you could just have a step that calls liquibase update from the commandline and bypass the plugin.

1 Like

I second Ronak’s reply with the bash workaround. That’s what we do… we have a simple loop that iterates thru the DBs as targets:

docker exec liquibase liquibase --url=“jdbc:mysql://0.0.0.0:3306/${DB}” update

1 Like

@erinlkolp Thank you. I’m currently using Maven in a similar fashion…

mvn --file pom.xml liquibase:update -Dliquibase.changeLogFile=master.changelog.xml -Dliquibase.propertyFile=liquibase.properties

2 Likes

I’ll hop on the shell script train as well. Store all of your actions in a shell script and just use Jenkins to execute actions in the script. It makes it so that you can test all of the build steps outside of Jenkins. Over reliance on plugins can lead to longer build/test/learn cycles as testing changes involves making the change, pushing to PR, watching jenkins run, debugging why jenkins didn’t do a thing, and repeat. Storing your actions outside of a specific CI tool can lead to greater portability should you need to move to another provider.

1 Like