Closed alexeyinkin closed 6 months ago
hi @alexeyinkin, for your use case I would recommend using the liquibase docker container instead of the default actions. The docker container allows you to setup custom workflows. You could do something like this:
jobs:
liquibase-update:
runs-on: ubuntu-latest
container:
image: liquibase/liquibase:4.27.0
steps:
- name: Checkout Code
uses: actions/checkout@v3
- name: Run Liquibase Update
working-directory: ./liquibase
run: |
liquibase update
I would like an action that just installs Liquibase so that I can run commands in subsequent steps. The current actions are inconvenient for me because:
liquibase
directory, and locally I run my commands in that directory. When a current action runs, I can't override the working directory, and so my calls on the local machine and a GitHub workflow differ substantially.liquibase.properties
file so that locally I can just runliquibase update
. However, the currentupdate
action requires me to havechangelogFile
parameter. This is a duplication as I already have it in myliquibase.properties
.liquibase/liquibase_lib
, and it's found automatically when I run commands inliquibase
directory. With current actions, it can't find the plugin because the working directory is different. So I must fiddle withclasspath
parameter as in #77This substantial complexity will go away entirely if I could just have