Conversation
Implements production-ready Docker image for Liquibase Enterprise (formerly Datical DB) with comprehensive testing and automation.
## Core Implementation
**DockerfileEnterprise**
- Multi-stage build using Eclipse Temurin 21 JRE
- Automated IzPack installer execution with xvfb for headless installation
- Java 21 module compatibility with --add-opens flags for Groovy reflection
- SHA256 verification for security (version 8.10.479)
- Non-root user (UID/GID 1001) for enhanced security
- Multi-platform support (linux/amd64, linux/arm64)
**autoInstall.xml**
- IzPack automated installation configuration
- Installs all 6 packages: UI, CLI, License Manager, Java Runtime, Oracle Client
- Configured for headless deployment
**docker-entrypoint-enterprise.sh**
- Automatic license detection from /liquibase/license/
- Sets DATDB_LICENSE environment variable for hammer CLI
- Auto-changes to /liquibase/project directory when mounted
- Intelligent command routing (OS commands vs hammer commands)
## Documentation
**README-enterprise.md**
- Quick Start with platform-specific examples (x86-64 and Apple Silicon)
- Verified working example with real version output
- Comprehensive feature documentation (Deployment Packager, Forecast & Deploy, etc.)
- Build instructions for AMD64, ARM64, and multi-platform
- Usage examples for all common scenarios (statusDetails, forecast, deploy, etc.)
- CI/CD integration examples (Jenkins, GitLab CI, GitHub Actions)
- Troubleshooting guide including Rosetta/Apple Silicon instructions
- License mounting documentation
**docker-compose.enterprise.yml**
- Complete example with PostgreSQL integration
- Health checks and service dependencies
- Volume mounting for projects and licenses
## GitHub Actions Workflows
**create-release-enterprise.yml**
- Automated version bumping in DockerfileEnterprise
- SHA256 calculation and validation
- Git tagging with v{version}-ENTERPRISE format
- Multi-platform builds (linux/amd64, linux/arm64)
- Publishes to Docker Hub, GHCR, and AWS ECR Public
- Dry-run mode with private ECR for testing
- Selective registry publishing (can disable any registry)
- GitHub release creation (draft mode)
**test-enterprise.yml**
- Comprehensive testing on ubuntu-latest and macos-15-intel
- Container structure validation (user, UID/GID, working directory)
- Java 21 installation verification
- hammer command availability checks
- DaticalDB installation structure validation
- Environment variable testing (LIQUIBASE_HOME, DOCKER_LIQUIBASE)
- Volume mount testing (license and project directories)
- License file mounting verification
- Project directory workflow validation
- Platform-specific tests for x86-64 hammer execution
**trivy-enterprise.yml**
- Surface and deep vulnerability scanning with Trivy
- SBOM generation with Syft
- Grype SBOM-based scanning
- Docker Scout CVE analysis
- Nested JAR and Python package extraction for comprehensive scanning
- SARIF upload to GitHub Security tab
- Enhanced vulnerability reports (90-day retention)
- Slack notifications on failure
- Scheduled scans (weekdays 7am UTC)
## Testing & Verification
- ✅ Built and tested on AMD64 platform
- ✅ Verified with valid Liquibase Enterprise license
- ✅ Confirmed hammer CLI execution (version 8.10.479)
- ✅ All component versions validated:
- Liquibase Enterprise Core 8.10.479
- Liquibase 3.5.11640
- Stored Logic extension 1.0.318
- AppDBA extension 1.0.474
- Java 11.0.15
- ✅ License mounting and DATDB_LICENSE environment variable working
- ✅ Docker Compose example functional
## Architecture Decisions
**Separate Workflows**: Enterprise uses dedicated workflows rather than being added to existing test.yml/trivy.yml matrix because:
- Different CLI interface (hammer vs liquibase)
- Unique requirements (license file testing)
- Longer build times (IzPack installation)
- Different test scenarios and commands
**Tag Format**: v{version}-ENTERPRISE prevents conflicts with Community (v{version}) and Secure (v{version}-SECURE) releases
**License Handling**: Runtime mounting (not build-time) ensures security and flexibility across environments
**Platform Support**: Multi-arch build with special considerations for Apple Silicon users (--platform flag documented)
Closes DAT-7679
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds official Liquibase Enterprise Docker support: new Changes
Sequence Diagram(s)sequenceDiagram
actor Trigger
participant GHA as "GitHub Actions"
participant Repo as "Repository"
participant RegHub as "Docker Hub"
participant RegGHCR as "GHCR"
participant RegECR as "ECR"
Trigger->>GHA: start release workflow
activate GHA
rect rgba(230,245,255,0.5)
Note over GHA: update-dockerfiles
GHA->>Repo: read inputs & secrets
GHA->>Repo: update `DockerfileEnterprise` (enterpriseVersion, jar SHA)
GHA->>Repo: commit & create tag (if not dry-run)
end
rect rgba(245,235,255,0.5)
Note over GHA: build-push-image
GHA->>GHA: generate tags & platforms
GHA->>GHA: build multi-arch image
alt push to Docker Hub
GHA->>RegHub: push
end
alt push to GHCR
GHA->>RegGHCR: push
end
alt push to ECR
GHA->>RegECR: push
end
GHA->>GHA: create GitHub release (non-dry-run)
end
deactivate GHA
sequenceDiagram
participant Container
participant Entrypoint as "docker-entrypoint-enterprise.sh"
participant Hammer as "hammer"
Container->>Entrypoint: start
activate Entrypoint
Entrypoint->>Entrypoint: detect license -> export DATDB_LICENSE
Entrypoint->>Entrypoint: set LIQUIBASE_HOME, PATH
alt first arg is an executable command
Entrypoint->>Container: exec "$@"
else
Entrypoint->>Hammer: exec hammer [args]
end
deactivate Entrypoint
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🔍 Vulnerabilities of
|
| digest | sha256:b75816b8ad456c115d5c9799c1db1932435d37d9835faf7abd468f197a3db542 |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 762 MB |
| packages | 425 |
📦 Base Image eclipse-temurin:21-jre
| also known as |
|
| digest | sha256:d665ca47131b82e94b17ec6b8d9ee72924268c509f9407a766ffe3d3defbaa32 |
| vulnerabilities |   |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
🔍 Vulnerabilities of
|
| digest | sha256:80eef08040498ca2b5e9b49b8b976f4beea2872201425e8034341a2fee94a6a8 |
| vulnerabilities |   |
| platform | linux/amd64 |
| size | 742 MB |
| packages | 639 |
📦 Base Image eclipse-temurin:21-jre
| also known as |
|
| digest | sha256:d665ca47131b82e94b17ec6b8d9ee72924268c509f9407a766ffe3d3defbaa32 |
| vulnerabilities | |
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description
|
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (5)
README-enterprise.md (2)
34-43: Add language identifier to fenced code block.The code block showing example output is missing a language identifier. Update the opening
```to```bashor```textfor consistency with other code blocks and to help renderers apply proper formatting.**Example output:** -``` +```bash Liquibase Enterprise CLI 8.10
345-355: Use markdown headings instead of bold emphasis.Lines 345 and 357 use bold emphasis (
**...**) where markdown headings (###) would be more semantically correct and improve document structure for navigation and tooling.-**Example: Adding PostgreSQL Client** +### Example: Adding PostgreSQL Client ```dockerfile-**Example: Adding SQL Server Tools** +### Example: Adding SQL Server Tools ```dockerfile.github/workflows/create-release-enterprise.yml (1)
145-163: Add quoting to shell variables and fix unused variable.Line 150 has unquoted variables that could break with special characters or spaces. Line 160 defines COMMIT_MSG but the variable is not used in the git commit command (string interpolation is used directly instead).
ENTERPRISE_SHA=$(curl -LsS https://software.datical.com/Datical_DB_Software/Datical_DB_${{ steps.collect-data.outputs.enterpriseVersion }}/DaticalDB-linux.gtk.x86_64-${{ steps.collect-data.outputs.enterpriseVersion }}.jar | sha256sum | awk '{ print $1 }') - sed -i 's/^ARG ENTERPRISE_VERSION=.*/ARG ENTERPRISE_VERSION='"${{ steps.collect-data.outputs.enterpriseVersion }}"'/' "${{ github.workspace }}/DockerfileEnterprise" - sed -i 's/^ARG ENT_JAR_SHA256=.*/ARG ENT_JAR_SHA256='"$ENTERPRISE_SHA"'/' "${{ github.workspace }}/DockerfileEnterprise" + sed -i "s/^ARG ENTERPRISE_VERSION=.*/ARG ENTERPRISE_VERSION=${{ steps.collect-data.outputs.enterpriseVersion }}/" "${{ github.workspace }}/DockerfileEnterprise" + sed -i "s/^ARG ENT_JAR_SHA256=.*/ARG ENT_JAR_SHA256=${ENTERPRISE_SHA}/" "${{ github.workspace }}/DockerfileEnterprise" git add DockerfileEnterprise if git diff-index --cached --quiet HEAD --; then echo "Nothing new to commit" echo "changes_made=false" >> $GITHUB_OUTPUT else - COMMIT_MSG="Liquibase Enterprise Version Bumped to ${{ steps.collect-data.outputs.enterpriseVersion }}" - git commit -m "${COMMIT_MSG}" + git commit -m "Liquibase Enterprise Version Bumped to ${{ steps.collect-data.outputs.enterpriseVersion }}".github/workflows/test-enterprise.yml (1)
195-218: Add quoting to shell variable expansions to handle paths with spaces.The command substitutions and path variables should be quoted to safely handle edge cases where paths contain spaces or special characters.
# Mount license file and verify it's accessible - RESULT=$(docker run --rm \ - -v $(pwd)/test-license:/liquibase/license \ + RESULT=$(docker run --rm \ + -v "$(pwd)/test-license:/liquibase/license" \ liquibase/liquibase-enterprise:${{ github.sha }} \ cat /liquibase/license/license.lic 2>&1)Apply similar quoting to lines 221 and 247.
DockerfileEnterprise (1)
59-65: Non-standard OCI label.
org.opencontainers.image.licenses.url(line 62) is not a standard OCI image-spec annotation. The standard label isorg.opencontainers.image.licenseswhich you've already set. Consider either removing the custom label or using a vendor-prefixed label likecom.liquibase.licenses.urlfor clarity.LABEL org.opencontainers.image.description="Liquibase Enterprise Container Image" LABEL org.opencontainers.image.licenses="LicenseRef-Datical-EULA" -LABEL org.opencontainers.image.licenses.url="https://www.datical.com/eula" +LABEL com.liquibase.eula.url="https://www.datical.com/eula" LABEL org.opencontainers.image.vendor="Liquibase"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (9)
.github/workflows/create-release-enterprise.yml(1 hunks).github/workflows/test-enterprise.yml(1 hunks).github/workflows/trivy-enterprise.yml(1 hunks).gitignore(1 hunks)DockerfileEnterprise(1 hunks)README-enterprise.md(1 hunks)autoInstall.xml(1 hunks)docker-entrypoint-enterprise.sh(1 hunks)examples/docker-compose/docker-compose.enterprise.yml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/Dockerfile*
📄 CodeRabbit inference engine (CLAUDE.md)
**/Dockerfile*: When extending Community images, useFROM liquibase/liquibase:latestas the base and add database drivers using LPM (e.g.,lpm add mysql --global)
When extending Secure images, useFROM liquibase/liquibase-secure:latestas the base and setLIQUIBASE_LICENSE_KEYenvironment variable
Files:
DockerfileEnterprise
🧠 Learnings (17)
📓 Common learnings
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Community images, use `FROM liquibase/liquibase:latest` as the base and add database drivers using LPM (e.g., `lpm add mysql --global`)
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,docker-compose.yml} : Docker Community images should use distinct tagging strategy: Git tag format `v{version}` (e.g., `v5.0.1`), GitHub Release labeled `v{version}`, and Docker image tags `liquibase/liquibase:{version}`, `liquibase/liquibase:{major.minor}`, and `liquibase/liquibase:latest`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Docker Secure images should use distinct tagging strategy: Git tag format `v{version}-SECURE` (e.g., `v5.0.1-SECURE`), GitHub Release labeled `v{version}-SECURE`, and Docker image tags `liquibase/liquibase-secure:{version}`, `liquibase/liquibase-secure:{major.minor}`, and `liquibase/liquibase-secure:latest`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Community Docker images should be published to Docker Hub as `liquibase/liquibase`, GitHub Container Registry as `ghcr.io/liquibase/liquibase*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase*`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Secure Docker images should be published to Docker Hub as `liquibase/liquibase-secure`, GitHub Container Registry as `ghcr.io/liquibase/liquibase-secure*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase-secure*`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : When adding tools or runtime dependencies to images, switch to root user, run apt-get operations, and switch back to non-root `liquibase` user in multi-step processes
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to Dockerfile : Community Liquibase versions should be sourced from GitHub releases and controlled via `LIQUIBASE_VERSION` ARG
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Secure images, use `FROM liquibase/liquibase-secure:latest` as the base and set `LIQUIBASE_LICENSE_KEY` environment variable
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set working directory to `/liquibase` in all Docker images
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Validate Liquibase and LPM binary SHA256 checksums for security in Dockerfile builds
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set `liquibase.docker.properties` default configuration file to enable headless mode in all images
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine,docker-entrypoint.sh} : Use `docker-entrypoint.sh` as the container entrypoint with automatic MySQL driver installation capability
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Secure Docker images should be published to Docker Hub as `liquibase/liquibase-secure`, GitHub Container Registry as `ghcr.io/liquibase/liquibase-secure*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase-secure*`
Applied to files:
.github/workflows/trivy-enterprise.ymlDockerfileEnterprise.github/workflows/create-release-enterprise.ymlREADME-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to docker-entrypoint.sh : Enable automatic changelog directory detection in `docker-entrypoint.sh`: detect `/liquibase/changelog` mount and change working directory for CLI-Docker compatibility, unless `SHOULD_CHANGE_DIR` environment variable explicitly overrides this behavior
Applied to files:
docker-entrypoint-enterprise.sh
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine,docker-entrypoint.sh} : Use `docker-entrypoint.sh` as the container entrypoint with automatic MySQL driver installation capability
Applied to files:
docker-entrypoint-enterprise.sh
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set working directory to `/liquibase` in all Docker images
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterprise.github/workflows/test-enterprise.ymlREADME-enterprise.mdexamples/docker-compose/docker-compose.enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : When adding tools or runtime dependencies to images, switch to root user, run apt-get operations, and switch back to non-root `liquibase` user in multi-step processes
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterprise.github/workflows/test-enterprise.yml.github/workflows/create-release-enterprise.ymlREADME-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Secure images, use `FROM liquibase/liquibase-secure:latest` as the base and set `LIQUIBASE_LICENSE_KEY` environment variable
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterpriseREADME-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set `liquibase.docker.properties` default configuration file to enable headless mode in all images
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterpriseexamples/docker-compose/docker-compose.enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Validate Liquibase and LPM binary SHA256 checksums for security in Dockerfile builds
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterprise.github/workflows/test-enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Community images, use `FROM liquibase/liquibase:latest` as the base and add database drivers using LPM (e.g., `lpm add mysql --global`)
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterprise.github/workflows/test-enterprise.ymlREADME-enterprise.mdexamples/docker-compose/docker-compose.enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to Dockerfile : Community Liquibase versions should be sourced from GitHub releases and controlled via `LIQUIBASE_VERSION` ARG
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterprise.github/workflows/test-enterprise.yml.github/workflows/create-release-enterprise.ymlREADME-enterprise.mdexamples/docker-compose/docker-compose.enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Create and use non-root `liquibase` user with UID/GID 1001 for running the container
Applied to files:
docker-entrypoint-enterprise.shDockerfileEnterpriseexamples/docker-compose/docker-compose.enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Docker Secure images should use distinct tagging strategy: Git tag format `v{version}-SECURE` (e.g., `v5.0.1-SECURE`), GitHub Release labeled `v{version}-SECURE`, and Docker image tags `liquibase/liquibase-secure:{version}`, `liquibase/liquibase-secure:{major.minor}`, and `liquibase/liquibase-secure:latest`
Applied to files:
DockerfileEnterprise.github/workflows/test-enterprise.yml.github/workflows/create-release-enterprise.ymlREADME-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Base image must use Eclipse Temurin JRE 21 (Jammy) as the foundation
Applied to files:
DockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Secure Liquibase versions should be sourced from repo.liquibase.com and controlled via `LIQUIBASE_PRO_VERSION` ARG
Applied to files:
DockerfileEnterpriseREADME-enterprise.mdexamples/docker-compose/docker-compose.enterprise.yml
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,docker-compose.yml} : Docker Community images should use distinct tagging strategy: Git tag format `v{version}` (e.g., `v5.0.1`), GitHub Release labeled `v{version}`, and Docker image tags `liquibase/liquibase:{version}`, `liquibase/liquibase:{major.minor}`, and `liquibase/liquibase:latest`
Applied to files:
.github/workflows/test-enterprise.yml.github/workflows/create-release-enterprise.ymlREADME-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Community Docker images should be published to Docker Hub as `liquibase/liquibase`, GitHub Container Registry as `ghcr.io/liquibase/liquibase*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase*`
Applied to files:
.github/workflows/create-release-enterprise.ymlREADME-enterprise.md
🪛 actionlint (1.7.8)
.github/workflows/trivy-enterprise.yml
246-246: shellcheck reported issue in this script: SC2086:info:2:56: Double quote to prevent globbing and word splitting
(shellcheck)
.github/workflows/test-enterprise.yml
47-47: shellcheck reported issue in this script: SC2086:info:4:24: Double quote to prevent globbing and word splitting
(shellcheck)
195-195: shellcheck reported issue in this script: SC2046:warning:9:6: Quote this to prevent word splitting
(shellcheck)
221-221: shellcheck reported issue in this script: SC2046:warning:9:6: Quote this to prevent word splitting
(shellcheck)
247-247: shellcheck reported issue in this script: SC2046:warning:9:6: Quote this to prevent word splitting
(shellcheck)
247-247: shellcheck reported issue in this script: SC2046:warning:23:6: Quote this to prevent word splitting
(shellcheck)
.github/workflows/create-release-enterprise.yml
145-145: shellcheck reported issue in this script: SC2086:info:13:32: Double quote to prevent globbing and word splitting
(shellcheck)
145-145: shellcheck reported issue in this script: SC2086:info:17:31: Double quote to prevent globbing and word splitting
(shellcheck)
168-168: shellcheck reported issue in this script: SC2034:warning:5:1: COMMIT_MSG appears unused. Verify use (or export if used externally)
(shellcheck)
217-217: shellcheck reported issue in this script: SC2086:info:2:56: Double quote to prevent globbing and word splitting
(shellcheck)
230-230: shellcheck reported issue in this script: SC2086:info:3:32: Double quote to prevent globbing and word splitting
(shellcheck)
230-230: shellcheck reported issue in this script: SC2086:info:4:40: Double quote to prevent globbing and word splitting
(shellcheck)
254-254: shellcheck reported issue in this script: SC2129:style:1:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
254-254: shellcheck reported issue in this script: SC2086:info:1:57: Double quote to prevent globbing and word splitting
(shellcheck)
254-254: shellcheck reported issue in this script: SC2086:info:2:66: Double quote to prevent globbing and word splitting
(shellcheck)
254-254: shellcheck reported issue in this script: SC2086:info:3:60: Double quote to prevent globbing and word splitting
(shellcheck)
288-288: property "aws_access_key_id" is not defined in object type {aws-access-key-id: string; aws-account-id: string; aws-expiration: string; aws-secret-access-key: string; aws-session-token: string}
(expression)
289-289: property "aws_secret_access_key" is not defined in object type {aws-access-key-id: string; aws-account-id: string; aws-expiration: string; aws-secret-access-key: string; aws-session-token: string}
(expression)
298-298: property "aws_access_key_id" is not defined in object type {aws-access-key-id: string; aws-account-id: string; aws-expiration: string; aws-secret-access-key: string; aws-session-token: string}
(expression)
299-299: property "aws_secret_access_key" is not defined in object type {aws-access-key-id: string; aws-account-id: string; aws-expiration: string; aws-secret-access-key: string; aws-session-token: string}
(expression)
303-303: shellcheck reported issue in this script: SC2086:info:37:24: Double quote to prevent globbing and word splitting
(shellcheck)
🪛 GitHub Check: CodeQL
.github/workflows/trivy-enterprise.yml
[warning] 43-43: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 50-50: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
[warning] 65-65: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'anchore/sbom-action' with ref 'v0', not a pinned commit hash
[warning] 80-80: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 91-91: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 102-102: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 115-115: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 128-128: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step: grype_scan uses 'anchore/scan-action' with ref 'v5', not a pinned commit hash
[warning] 159-159: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'rtCamp/action-slack-notify' with ref 'v2', not a pinned commit hash
[warning] 199-199: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'rsdmike/github-security-report-action' with ref 'v3.0.4', not a pinned commit hash
[warning] 232-232: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 239-239: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
[warning] 250-250: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'docker/login-action' with ref 'v3', not a pinned commit hash
[warning] 256-256: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'docker/scout-action' with ref 'v1.18.2', not a pinned commit hash
[warning] 269-269: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'rtCamp/action-slack-notify' with ref 'v2', not a pinned commit hash
[warning] 289-289: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'rsdmike/github-security-report-action' with ref 'v3.0.4', not a pinned commit hash
.github/workflows/test-enterprise.yml
[warning] 40-40: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Liquibase Enterprise Dockerfile' step Uses Step uses 'douglascamata/setup-docker-macos-action' with ref 'v1.0.2', not a pinned commit hash
.github/workflows/create-release-enterprise.yml
[warning] 103-103: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 110-110: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
[warning] 203-203: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 210-210: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
[warning] 239-239: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'softprops/action-gh-release' with ref 'v2', not a pinned commit hash
[warning] 249-249: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/setup-qemu-action' with ref 'v3', not a pinned commit hash
[warning] 250-250: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
[warning] 261-261: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/login-action' with ref 'v3', not a pinned commit hash
[warning] 268-268: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/login-action' with ref 'v3', not a pinned commit hash
[warning] 276-276: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step: configure-aws-credentials-prod uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 283-283: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/login-action' with ref 'v3', not a pinned commit hash
[warning] 293-293: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/login-action' with ref 'v3', not a pinned commit hash
[warning] 348-348: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'docker/build-push-action' with ref 'v6', not a pinned commit hash
🪛 markdownlint-cli2 (0.18.1)
README-enterprise.md
34-34: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
345-345: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
357-357: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: Scout Scan - Liquibase Enterprise
- GitHub Check: Trivy Scan - Liquibase Enterprise
- GitHub Check: Build & Test DockerfileEnterprise - macos-15-intel
- GitHub Check: Build & Test DockerfileEnterprise - ubuntu-latest
- GitHub Check: Build & Test Dockerfile - macos-15-intel
- GitHub Check: Build & Test DockerfileSecure - ubuntu-latest
- GitHub Check: Build & Test Dockerfile.alpine - ubuntu-latest
- GitHub Check: Build & Test Dockerfile.alpine - macos-15-intel
- GitHub Check: Build & Test DockerfileSecure - macos-15-intel
- GitHub Check: Build & Test Dockerfile - ubuntu-latest
- GitHub Check: Trivy (DockerfileSecure, liquibase/liquibase-secure)
- GitHub Check: Scout (DockerfileSecure, liquibase/liquibase-secure)
- GitHub Check: Trivy (Dockerfile.alpine, liquibase/liquibase, -alpine)
- GitHub Check: Trivy (Dockerfile, liquibase/liquibase)
🔇 Additional comments (14)
.gitignore (1)
3-3: LGTM!The addition of
*.licto gitignore appropriately prevents accidental license file commits, which is important for security and privacy when handling customer-provided enterprise licenses.autoInstall.xml (1)
1-23: LGTM!The IzPack configuration is well-structured and correctly defaults to the paths expected by the entrypoint script and Docker Compose examples. The five selected packages and target installation path align with the PR objectives.
README-enterprise.md (1)
1-507: Comprehensive documentation with strong coverage of enterprise features.The README provides excellent guidance on licensing, registry options, build instructions, multi-platform support, CI/CD integration patterns, and troubleshooting. Documentation aligns well with the runtime behavior implemented in docker-entrypoint-enterprise.sh and the examples provided in docker-compose.enterprise.yml.
examples/docker-compose/docker-compose.enterprise.yml (1)
1-41: LGTM!The Docker Compose example correctly demonstrates Liquibase Enterprise usage with service dependencies, volume mounts for license/project, and health checks. The configuration aligns with the documentation and entrypoint behavior.
docker-entrypoint-enterprise.sh (1)
1-28: LGTM!The entrypoint script correctly implements license auto-detection, project directory mounting, and intelligent command routing. The logic appropriately defaults to hammer commands while allowing direct OS command execution for flexibility (e.g., bash, cat). The
set -esafety flag and dual license path checks are well-considered..github/workflows/create-release-enterprise.yml (1)
172-181: LGTM!Tag format
v{version}-ENTERPRISEcorrectly follows the established pattern from learnings for enterprise images. Multi-platform build setup and registry logic are sound..github/workflows/trivy-enterprise.yml (2)
1-300: Comprehensive vulnerability scanning with good tooling coverage.The workflow provides thorough scanning including surface/deep vulnerability analysis, SBOM generation, multiple scanners (Trivy, Grype, Docker Scout), SARIF uploads for visibility, and scheduled runs. Architecture aligns well with enterprise security requirements.
62-62: All helper scripts are present and executable in the repository.Verification confirms that all four helper scripts referenced in the workflow exist and have proper executable permissions:
- ✅ scripts/extract-nested-deps.sh
- ✅ scripts/save-grype-results.sh
- ✅ scripts/analyze-scan-results.sh
- ✅ scripts/check-file-exists.sh
No action required on this workflow.
.github/workflows/test-enterprise.yml (1)
1-337: Excellent comprehensive testing with good platform awareness.The test workflow validates core container functionality (structure, Java, hammer CLI, directories, environment, volumes, entrypoint behavior, licensing, project mounting) with appropriate platform-specific handling for x86-64 vs ARM64. Well-structured assertions, good cleanup, and informative test output make this a strong validation suite.
DockerfileEnterprise (5)
1-9: LGTM!Builder stage correctly uses Eclipse Temurin JRE 21 base and efficiently combines apt-get operations in a single layer with proper cleanup. The xvfb installation is appropriate for the headless IzPack GUI installer requirement.
11-17: Secure download with SHA256 validation.Good implementation of installer download with checksum verification. The version is properly parameterized via ARG, following the established pattern for version control. Based on learnings, SHA256 validation is required for security.
19-38: LGTM - Java 21 module compatibility handled correctly.The extensive
--add-opensflags are necessary for Java 21's stricter module system when running IzPack with Groovy reflection. The headless installation via xvfb-run and subsequent cleanup of installer artifacts follows multi-stage build best practices.
40-55: LGTM - Follows security guidelines with OpenShift compatibility.Correctly creates non-root
liquibaseuser with UID/GID 1001 as per guidelines. Theliquibase:rootgroup ownership withg+rxpermissions is a good pattern for OpenShift/Kubernetes environments where containers may run with arbitrary UIDs. Working directory properly set to/liquibase. Based on learnings, this follows the established pattern.
74-84: LGTM - Proper entrypoint configuration with non-root execution.Efficient use of
COPY --chmod=755to set execute permissions in a single layer. Correctly switches to non-rootliquibase:liquibaseuser before defining volumes and entrypoint. The default CMD providinghammer --helpis user-friendly for discovery. Based on learnings, switching to non-root user after privileged operations follows the established pattern.
| uses: aws-actions/configure-aws-credentials@v5 | ||
| with: | ||
| role-to-assume: ${{ secrets.LIQUIBASE_VAULT_OIDC_ROLE_ARN }} | ||
| aws-region: us-east-1 | ||
|
|
||
| - name: Get secrets from vault | ||
| id: vault-secrets | ||
| uses: aws-actions/aws-secretsmanager-get-secrets@v2 | ||
| with: | ||
| secret-ids: | | ||
| ,/vault/liquibase | ||
| parse-json-secrets: true | ||
|
|
||
| - name: Get GitHub App token | ||
| id: get-token | ||
| uses: actions/create-github-app-token@v2 | ||
| with: | ||
| app-id: ${{ env.LIQUIBASE_GITHUB_APP_ID }} | ||
| private-key: ${{ env.LIQUIBASE_GITHUB_APP_PRIVATE_KEY }} | ||
| owner: ${{ github.repository_owner }} | ||
| permission-contents: write | ||
|
|
||
| - uses: actions/checkout@v6 | ||
| with: | ||
| persist-credentials: false | ||
| ref: ${{ github.ref }} | ||
| token: ${{ steps.get-token.outputs.token }} | ||
| fetch-depth: 0 |
There was a problem hiding this comment.
🧩 Analysis chain
Pin GitHub Actions to commit hashes for supply chain security.
Multiple third-party actions use version tags (v5, v2, v3, etc.) instead of commit hashes. While version tags are more maintainable, pinning to commit hashes provides stronger protection against supply chain attacks. This is a broader security hardening recommendation for the organization.
Consider pinning key actions to commit SHAs, particularly those handling secrets/credentials:
aws-actions/configure-aws-credentials@v5→aws-actions/configure-aws-credentials@<commit-hash>aws-actions/aws-secretsmanager-get-secrets@v2→ similarsoftprops/action-gh-release@v2→ similar
This would require regular updates when new versions are released, but provides stronger security guarantees.
I'll verify this review comment by examining the workflow file and checking current best practices for GitHub Actions pinning.
🏁 Script executed:
#!/bin/bash
# Find and examine the create-release-enterprise workflow file
find . -name "create-release-enterprise.yml" -type f | head -5 | xargs -I {} cat {}Length of output: 15885
🌐 Web query:
GitHub Actions pinning commit hashes vs version tags security best practices 2024
💡 Result:
Summary — 2024 best practice (concise)
- Strong recommendation: pin third‑party Actions to a full‑length commit SHA (immutable). This is the most secure option against tag‑moves and malicious updates. [1][2]
- Tags (e.g., @V3) are convenient but riskier: tags can be moved/recreated if a repo is compromised — only use tags for authors you fully trust (prefer Verified creators) and accept the risk. [1][2]
- Watch for “unpinnable” Actions (they pull dynamic code or remote artifacts): pinning the SHA doesn’t neutralize those risks — avoid or audit them. [2]
- Governance: enable/require SHA pinning and/or block specific actions at org/repo level via GitHub’s allowed‑actions policy. This central enforcement is recommended for organizations. [2][4]
- Tooling & maintenance tradeoffs:
- Pinning SHAs improves security but makes updates manual. Add the human‑readable tag/version in a comment next to the SHA to track versions. [2]
- Dependabot/alerting caveat: Dependabot alerts and some automated updates rely on semver tags and won’t create alerts for actions pinned to SHAs — plan compensating monitoring. [1]
- Use automation (scripts/actions) to pin SHAs and to periodically refresh/verify pinned SHAs from upstream. [5][6]
- Practical minimal checklist:
- Pin third‑party actions to full commit SHAs. [1][2]
- Enable org/repo policy to enforce SHA pinning and blocklisted actions. [2][4]
- Audit action code (or use Verified creators), avoid unpinnable actions. [1][2][3]
- Maintain a lightweight process to update SHAs and monitor advisories (Dependabot + manual checks for SHA‑pinned actions). [1][3]
Sources
[1] GitHub Docs — Security hardening for GitHub Actions (pin to full SHA; Dependabot caveat). (docs.github.com)
[2] GitHub Well‑Architected / Actions security (recommend SHA pinning; unpinnable actions). (wellarchitected.github.com)
[3] Snyk Labs — supply‑chain guidance for GitHub Actions (recommend pinning to commit SHAs). (labs.snyk.io)
[4] GitHub changelog — policy: enforce SHA pinning / block actions. (github.blog)
[5] pinsha / tooling examples (automation to pin SHAs). (zkamvar.github.io)
Citations:
- 1: https://docs.github.com/actions/learn-github-actions/security-hardening-for-github-actions?utm_source=openai
- 2: https://wellarchitected.github.com/library/application-security/recommendations/actions-security/?utm_source=openai
- 3: https://labs.snyk.io/resources/exploring-vulnerabilities-github-actions/?utm_source=openai
- 4: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/?utm_source=openai
- 5: https://zkamvar.github.io/pinsha/?utm_source=openai
Pin GitHub Actions to commit hashes for supply chain security.
Multiple third-party actions use version tags (v5, v2, v3, etc.) instead of commit hashes. Version tags are convenient but riskier because tags can be moved or recreated if a repository is compromised. Pinning to full-length commit SHAs is the recommended approach for stronger protection against supply chain attacks.
Update these actions in your workflow:
aws-actions/configure-aws-credentials@v5(lines 95, 206)aws-actions/aws-secretsmanager-get-secrets@v2(lines 101, 148)softprops/action-gh-release@v2(line 234)actions/create-github-app-token@v2(line 108)
Add a human-readable tag or version in a comment next to each SHA to track versions, and plan for periodic updates when upstream actions release new versions.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 103-103: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 110-110: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release Liquibase Enterprise' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
| ENTERPRISE_SHA=$(curl -LsS https://software.datical.com/Datical_DB_Software/Datical_DB_${{ steps.collect-data.outputs.enterpriseVersion }}/DaticalDB-linux.gtk.x86_64-${{ steps.collect-data.outputs.enterpriseVersion }}.jar | sha256sum | awk '{ print $1 }') | ||
|
|
||
| sed -i 's/^ARG ENTERPRISE_VERSION=.*/ARG ENTERPRISE_VERSION='"${{ steps.collect-data.outputs.enterpriseVersion }}"'/' "${{ github.workspace }}/DockerfileEnterprise" | ||
| sed -i 's/^ARG ENT_JAR_SHA256=.*/ARG ENT_JAR_SHA256='"$ENTERPRISE_SHA"'/' "${{ github.workspace }}/DockerfileEnterprise" |
There was a problem hiding this comment.
Add SHA256 verification against known value.
Line 150 downloads the enterprise JAR's SHA256 hash but never validates it against a known/expected value. This means a man-in-the-middle or compromised download could introduce a malicious installer. The workflow should verify the hash matches an expected value from a trusted source.
Consider either:
- Maintain a hardcoded hash for each version in the workflow
- Fetch the hash from a signed/verified source
- Check against a manifest maintained in the repository
Example approach (fetch from signed manifest):
# Example - adapt based on actual manifest location/format
EXPECTED_SHA=$(curl -s https://trusted-source/hashes.txt | grep "DaticalDB-linux.*${{ steps.collect-data.outputs.enterpriseVersion }}" | awk '{print $1}')
ACTUAL_SHA=$(curl -LsS https://software.datical.com/... | sha256sum | awk '{ print $1 }')
if [ "$EXPECTED_SHA" != "$ACTUAL_SHA" ]; then
echo "SHA256 verification failed!"
exit 1
fi🤖 Prompt for AI Agents
.github/workflows/create-release-enterprise.yml around lines 150-153: the
workflow computes ENTERPRISE_SHA from the downloaded JAR but never verifies it;
add a verification step before updating DockerfileEnterprise that obtains the
expected SHA from a trusted source (hardcoded map per version, a signed manifest
fetched from a trusted URL, or a repo-maintained manifest), compare the
EXPECTED_SHA to the ACTUAL_SHA, and if they differ print an error and exit
non-zero so the job fails; only proceed to sed/update the DockerfileEnterprise
when the hashes match.
| uses: aws-actions/configure-aws-credentials@v5 | ||
| with: | ||
| role-to-assume: ${{ secrets.LIQUIBASE_VAULT_OIDC_ROLE_ARN }} | ||
| aws-region: us-east-1 | ||
|
|
||
| - name: Get secrets from vault | ||
| id: vault-secrets | ||
| uses: aws-actions/aws-secretsmanager-get-secrets@v2 | ||
| with: | ||
| secret-ids: | | ||
| ,/vault/liquibase | ||
| parse-json-secrets: true | ||
|
|
||
| - name: Build liquibase/liquibase-enterprise from DockerfileEnterprise | ||
| run: | | ||
| docker build -f DockerfileEnterprise -t liquibase/liquibase-enterprise:${{ github.sha }} . | ||
|
|
||
| - name: Extract nested JARs and Python packages for deep scanning | ||
| run: | | ||
| scripts/extract-nested-deps.sh liquibase/liquibase-enterprise:${{ github.sha }} | ||
|
|
||
| - name: Generate SBOM with Syft | ||
| uses: anchore/sbom-action@v0 | ||
| with: | ||
| image: "liquibase/liquibase-enterprise:${{ github.sha }}" | ||
| format: "spdx-json" | ||
| output-file: "sbom.spdx.json" | ||
|
|
||
| - name: Upload SBOM as artifact | ||
| if: always() | ||
| uses: actions/upload-artifact@v5 | ||
| with: | ||
| name: sbom-enterprise | ||
| path: sbom.spdx.json | ||
| retention-days: 30 | ||
|
|
||
| - name: Run Trivy vulnerability scanner (Surface Scan - SARIF) | ||
| uses: aquasecurity/trivy-action@0.33.1 | ||
| with: | ||
| image-ref: "liquibase/liquibase-enterprise:${{ github.sha }}" | ||
| vuln-type: "os,library" | ||
| format: "sarif" | ||
| output: "trivy-surface.sarif" | ||
| severity: "HIGH,CRITICAL" | ||
| exit-code: "0" | ||
| limit-severities-for-sarif: true | ||
|
|
||
| - name: Run Trivy vulnerability scanner (Surface Scan - JSON) | ||
| uses: aquasecurity/trivy-action@0.33.1 | ||
| with: | ||
| image-ref: "liquibase/liquibase-enterprise:${{ github.sha }}" | ||
| vuln-type: "os,library" | ||
| format: "json" | ||
| output: "trivy-surface.json" | ||
| severity: "HIGH,CRITICAL" | ||
| exit-code: "0" | ||
|
|
||
| - name: Run Trivy scanner on extracted nested JARs (Deep Scan - SARIF) | ||
| if: always() | ||
| uses: aquasecurity/trivy-action@0.33.1 | ||
| with: | ||
| scan-type: "rootfs" | ||
| scan-ref: "/tmp/extracted-deps" | ||
| vuln-type: "library" | ||
| format: "sarif" | ||
| output: "trivy-deep.sarif" | ||
| severity: "HIGH,CRITICAL" | ||
| exit-code: "0" | ||
| limit-severities-for-sarif: true | ||
|
|
||
| - name: Run Trivy scanner on extracted nested JARs (Deep Scan - JSON) | ||
| if: always() | ||
| uses: aquasecurity/trivy-action@0.33.1 | ||
| with: | ||
| scan-type: "rootfs" | ||
| scan-ref: "/tmp/extracted-deps" | ||
| vuln-type: "library" | ||
| format: "json" | ||
| output: "trivy-deep.json" | ||
| severity: "HIGH,CRITICAL" | ||
| exit-code: "0" | ||
|
|
||
| - name: Run Grype scanner on SBOM | ||
| if: always() | ||
| id: grype_scan | ||
| uses: anchore/scan-action@v5 | ||
| with: | ||
| sbom: "sbom.spdx.json" | ||
| fail-build: false | ||
| severity-cutoff: high | ||
| output-format: sarif | ||
| continue-on-error: true | ||
|
|
||
| - name: Save Grype results to file | ||
| if: always() | ||
| run: | | ||
| scripts/save-grype-results.sh | ||
|
|
||
| - name: Combine scan results and check for failures | ||
| if: always() | ||
| env: | ||
| IMAGE_NAME: liquibase/liquibase-enterprise | ||
| IMAGE_SUFFIX: "" | ||
| run: | | ||
| scripts/analyze-scan-results.sh | ||
|
|
||
| - name: Upload enhanced vulnerability report | ||
| if: always() | ||
| uses: actions/upload-artifact@v5 | ||
| with: | ||
| name: vulnerability-report-enterprise | ||
| path: vulnerability-report-enhanced.md | ||
| retention-days: 90 | ||
|
|
||
| - name: Notify Slack on Build Failure | ||
| if: failure() | ||
| uses: rtCamp/action-slack-notify@v2 | ||
| env: | ||
| SLACK_COLOR: "failure" | ||
| SLACK_MESSAGE: "View details on GitHub Actions: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}. Triggered by repository: ${{ github.repository }} and job: ${{ github.job }}" | ||
| SLACK_TITLE: "❌ ${{ github.repository }} ❌ Trivy failed on branch ${{ github.ref_name }} for commit ${{ github.sha }} in repository ${{ github.repository }}" | ||
| SLACK_USERNAME: liquibot | ||
| SLACK_WEBHOOK: ${{ env.DOCKER_SLACK_WEBHOOK_URL }} | ||
| SLACK_ICON_EMOJI: ":whale:" | ||
| SLACK_FOOTER: "${{ github.repository }} - liquibase/liquibase-enterprise:${{ github.sha }}" | ||
| SLACK_LINK_NAMES: true | ||
|
|
||
| - name: Upload Trivy Surface scan results to GitHub Security tab | ||
| if: always() | ||
| uses: github/codeql-action/upload-sarif@v4 | ||
| with: | ||
| sarif_file: "trivy-surface.sarif" | ||
| category: "liquibase/liquibase-enterprise-surface" | ||
|
|
||
| - name: Upload Trivy Deep scan results to GitHub Security tab | ||
| if: always() | ||
| uses: github/codeql-action/upload-sarif@v4 | ||
| with: | ||
| sarif_file: "trivy-deep.sarif" | ||
| category: "liquibase/liquibase-enterprise-deep" | ||
|
|
||
| - name: Check if Grype SARIF exists | ||
| if: always() | ||
| id: check_grype | ||
| run: | | ||
| scripts/check-file-exists.sh grype-results.sarif exists | ||
|
|
||
| - name: Upload Grype scan results to GitHub Security tab | ||
| if: always() && steps.check_grype.outputs.exists == 'true' | ||
| uses: github/codeql-action/upload-sarif@v4 | ||
| with: | ||
| sarif_file: "grype-results.sarif" | ||
| category: "liquibase/liquibase-enterprise-grype" | ||
|
|
||
| - name: Generate Security Report | ||
| if: always() | ||
| uses: rsdmike/github-security-report-action@v3.0.4 | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| outputDir: ./reports/trivy-enterprise/ | ||
| sarifReportDir: . | ||
|
|
||
| - name: Upload Security Report | ||
| if: always() | ||
| uses: actions/upload-artifact@v5 | ||
| with: | ||
| name: security-report-trivy-enterprise | ||
| path: ./reports/trivy-enterprise/summary.pdf | ||
|
|
||
| - name: Upload Scan Summary | ||
| if: always() | ||
| uses: actions/upload-artifact@v5 | ||
| with: | ||
| name: scan-summary-enterprise |
There was a problem hiding this comment.
Supply chain security: Pin GitHub Actions to commit hashes.
Similar to create-release-enterprise.yml, this workflow uses unpinned action versions (v5, v2, v0, 0.33.1, etc.). Pin these to commit hashes for stronger protection against supply chain attacks, particularly for security-sensitive operations.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 43-43: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 50-50: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
[warning] 65-65: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'anchore/sbom-action' with ref 'v0', not a pinned commit hash
[warning] 80-80: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 91-91: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 102-102: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 115-115: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'aquasecurity/trivy-action' with ref '0.33.1', not a pinned commit hash
[warning] 128-128: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step: grype_scan uses 'anchore/scan-action' with ref 'v5', not a pinned commit hash
[warning] 159-159: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'rtCamp/action-slack-notify' with ref 'v2', not a pinned commit hash
[warning] 199-199: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Liquibase Enterprise Vulnerability Scanning' step Uses Step uses 'rsdmike/github-security-report-action' with ref 'v3.0.4', not a pinned commit hash
🤖 Prompt for AI Agents
.github/workflows/trivy-enterprise.yml lines 43-216: multiple "uses:
owner/action@vX" entries are unpinned which is a supply-chain risk; replace each
tagged version with the corresponding full commit SHA from the action's
repository (e.g., aws-actions/configure-aws-credentials@<commit-sha>), keeping
the same owner/repo path, and update all occurrences
(aws-actions/configure-aws-credentials,
aws-actions/aws-secretsmanager-get-secrets, anchore/sbom-action,
actions/upload-artifact, aquasecurity/trivy-action, anchore/scan-action,
rtCamp/action-slack-notify, github/codeql-action/upload-sarif,
rsdmike/github-security-report-action, etc.); to fix, look up the latest stable
commit SHA for each action on its GitHub repo, replace the @version with
@<full-commit-sha> in this workflow, and commit the change (optionally add a
short comment linking to the SHA sources for future maintenance).
Fixed the failing GitHub Actions test workflow for Enterprise image by: 1. **Added AWS Secrets Manager integration**: - Added id-token: write permission for OIDC authentication - Configured AWS credentials using liquibase vault OIDC role - Retrieved ENTERPRISE_LICENSE from /vault/liquibase secret - Created test-license/license.lic file from vault secret 2. **Fixed entrypoint script test**: - Added set +e/set -e to handle non-zero exit codes - Mount real license file during test - Updated grep pattern to include more keywords (options, datical) - Prevents test failure when hammer exits with error code 3. **Updated platform-specific tests**: - Mount license file for 'hammer show version' test - Updated test description to reflect license usage - Changed grep pattern to check for CLI/Core version info 4. **Updated license mounting test**: - Renamed from "without actual license" to "with real license" - Removed dummy license file creation - Use real license from vault instead - Check for non-empty license content 5. **Added cleanup step**: - Added "Cleanup license file" step with if: always() - Ensures license is removed from runner after tests - Updated summary notes to reflect vault usage This ensures all tests can properly verify hammer functionality with a valid license while maintaining security by fetching credentials from AWS Secrets Manager. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/test-enterprise.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Community images, use `FROM liquibase/liquibase:latest` as the base and add database drivers using LPM (e.g., `lpm add mysql --global`)
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,docker-compose.yml} : Docker Community images should use distinct tagging strategy: Git tag format `v{version}` (e.g., `v5.0.1`), GitHub Release labeled `v{version}`, and Docker image tags `liquibase/liquibase:{version}`, `liquibase/liquibase:{major.minor}`, and `liquibase/liquibase:latest`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Community Docker images should be published to Docker Hub as `liquibase/liquibase`, GitHub Container Registry as `ghcr.io/liquibase/liquibase*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase*`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Docker Secure images should use distinct tagging strategy: Git tag format `v{version}-SECURE` (e.g., `v5.0.1-SECURE`), GitHub Release labeled `v{version}-SECURE`, and Docker image tags `liquibase/liquibase-secure:{version}`, `liquibase/liquibase-secure:{major.minor}`, and `liquibase/liquibase-secure:latest`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Secure Docker images should be published to Docker Hub as `liquibase/liquibase-secure`, GitHub Container Registry as `ghcr.io/liquibase/liquibase-secure*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase-secure*`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to Dockerfile : Community Liquibase versions should be sourced from GitHub releases and controlled via `LIQUIBASE_VERSION` ARG
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Secure images, use `FROM liquibase/liquibase-secure:latest` as the base and set `LIQUIBASE_LICENSE_KEY` environment variable
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set working directory to `/liquibase` in all Docker images
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : When adding tools or runtime dependencies to images, switch to root user, run apt-get operations, and switch back to non-root `liquibase` user in multi-step processes
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set `liquibase.docker.properties` default configuration file to enable headless mode in all images
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to docker-entrypoint.sh : Enable automatic changelog directory detection in `docker-entrypoint.sh`: detect `/liquibase/changelog` mount and change working directory for CLI-Docker compatibility, unless `SHOULD_CHANGE_DIR` environment variable explicitly overrides this behavior
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine,docker-entrypoint.sh} : Use `docker-entrypoint.sh` as the container entrypoint with automatic MySQL driver installation capability
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Validate Liquibase and LPM binary SHA256 checksums for security in Dockerfile builds
Applied to files:
.github/workflows/test-enterprise.yml
🪛 GitHub Check: CodeQL
.github/workflows/test-enterprise.yml
[warning] 40-40: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Liquibase Enterprise Dockerfile' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
[warning] 47-47: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Liquibase Enterprise Dockerfile' step Uses Step: vault-secrets uses 'aws-actions/aws-secretsmanager-get-secrets' with ref 'v2', not a pinned commit hash
[warning] 61-61: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Liquibase Enterprise Dockerfile' step Uses Step uses 'douglascamata/setup-docker-macos-action' with ref 'v1.0.2', not a pinned commit hash
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: Build & Test DockerfileSecure - ubuntu-latest
- GitHub Check: Build & Test DockerfileSecure - macos-15-intel
- GitHub Check: Build & Test Dockerfile.alpine - ubuntu-latest
- GitHub Check: Build & Test Dockerfile - ubuntu-latest
- GitHub Check: Build & Test Dockerfile - macos-15-intel
- GitHub Check: Build & Test Dockerfile.alpine - macos-15-intel
- GitHub Check: Scout Scan - Liquibase Enterprise
- GitHub Check: Trivy Scan - Liquibase Enterprise
- GitHub Check: Build & Test DockerfileEnterprise - ubuntu-latest
- GitHub Check: Build & Test DockerfileEnterprise - macos-15-intel
- GitHub Check: Trivy (Dockerfile.alpine, liquibase/liquibase, -alpine)
- GitHub Check: Scout (DockerfileSecure, liquibase/liquibase-secure)
- GitHub Check: Trivy (DockerfileSecure, liquibase/liquibase-secure)
- GitHub Check: Trivy (Dockerfile, liquibase/liquibase)
🔇 Additional comments (3)
.github/workflows/test-enterprise.yml (3)
72-72: Review soft error suppression that may mask real test failures.Multiple test steps use
|| trueorset +eto suppress errors:
- Line 72:
docker run ... || true— silently ignores failure- Lines 191, 195:
set +ebefore docker run, thenset -eafter — disables strict error checkingThese patterns risk hiding genuine failures. If the entrypoint test at line 189–207 is meant to validate hammer execution, it should fail loudly on unexpected errors, not warn softly. Verify whether permissive error handling is intentional or should be tightened to catch regressions.
Also applies to: 191-191, 195-195
270-289: Clarify working directory change test expectations against entrypoint contract.Lines 270–289 test whether the working directory changes to
/liquibase/projectwhen a project volume is mounted. However, line 286–289 only issues a warning if the directory does not change, suggesting the behavior is optional:else echo "⚠️ Note: Working directory did not change (may be expected behavior)" fiBased on learnings about
docker-entrypoint.sh, automatic directory change should be triggered when/liquibase/projectis mounted. If that is the expected contract, this test should fail hard on mismatch. If it is optional or platform-dependent, clarify the entrypoint spec or gate the test to x86-64 only (as done in lines 323–346).
364-368: Strengthen cleanup to handle partial test failure scenarios.The cleanup step (line 364–368) only removes
test-license, which is safe because it will succeed even if the step that created it failed. However, inline cleanups at lines 268 and 306 depend on tests reaching those lines. If an earlier assertion fails, temporary directories may persist.Consider adding a more robust cleanup:
- name: Cleanup license file if: always() run: | rm -rf test-license + rm -rf test-project test-project-workdir echo "Temporary test files cleaned up"This ensures all transient artifacts are removed regardless of which test fails.
| uses: actions/checkout@v6 | ||
|
|
||
| - name: Configure AWS credentials for vault access | ||
| uses: aws-actions/configure-aws-credentials@v5 |
There was a problem hiding this comment.
🧩 Analysis chain
Pin Actions to immutable commit hashes for supply-chain security.
CodeQL flags three unpinned Actions:
- Line 40:
aws-actions/configure-aws-credentials@v5 - Line 47:
aws-actions/aws-secretsmanager-get-secrets@v2 - Line 61:
douglascamata/setup-docker-macos-action@v1.0.2
Pinning to commit SHAs prevents accidental or malicious updates to Actions.
Also applies to: 47-47, 61-61
🏁 Script executed:
#!/bin/bash
# Check current commit hashes for each Action
echo "Fetching action commit hashes..."
curl -s "https://api.github.com/repos/aws-actions/configure-aws-credentials/commits?per_page=1&ref=v5" | jq '.[0].sha' | head -c 10
echo " (aws-actions/configure-aws-credentials@v5)"
curl -s "https://api.github.com/repos/aws-actions/aws-secretsmanager-get-secrets/commits?per_page=1&ref=v2" | jq '.[0].sha' | head -c 10
echo " (aws-actions/aws-secretsmanager-get-secrets@v2)"
curl -s "https://api.github.com/repos/douglascamata/setup-docker-macos-action/commits?per_page=1&ref=v1.0.2" | jq '.[0].sha' | head -c 10
echo " (douglascamata/setup-docker-macos-action@v1.0.2)"Length of output: 205
Pin GitHub Actions to immutable commit hashes for supply-chain security.
Unpinned action versions introduce supply-chain risk. Pin the following to their commit hashes:
- Line 40:
aws-actions/configure-aws-credentials@v5→ pin toc2d97f116 - Line 47:
aws-actions/aws-secretsmanager-get-secrets@v2→ pin to8d2df8d4e - Line 61:
douglascamata/setup-docker-macos-action@v1.0.2→ pin to1a5b5b065
Using semantic version tags allows unauthorized code changes to run in your CI pipeline. Pinning prevents this.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 40-40: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Liquibase Enterprise Dockerfile' step Uses Step uses 'aws-actions/configure-aws-credentials' with ref 'v5', not a pinned commit hash
🤖 Prompt for AI Agents
.github/workflows/test-enterprise.yml lines 40, 47 and 61: the workflow is using
floating action tags which create supply-chain risk; update the action
references to immutable commit SHAs by replacing
aws-actions/configure-aws-credentials@v5 with
aws-actions/configure-aws-credentials@c2d97f116 (line 40),
aws-actions/aws-secretsmanager-get-secrets@v2 with
aws-actions/aws-secretsmanager-get-secrets@8d2df8d4e (line 47), and
douglascamata/setup-docker-macos-action@v1.0.2 with
douglascamata/setup-docker-macos-action@1a5b5b065 (line 61); ensure the exact
commit hashes are used and run the workflow to verify no behavior changes.
| - name: Write license file for testing | ||
| run: | | ||
| mkdir -p test-license | ||
| echo "${{ steps.vault-secrets.outputs.ENTERPRISE_LICENSE }}" > test-license/license.lic | ||
| chmod 644 test-license/license.lic |
There was a problem hiding this comment.
Mitigate secrets leakage and use safe redirection for license file.
Line 56 echoes a vault secret directly into a file. While GitHub Actions masks secrets in logs, this is risky; prefer using a temporary file with restricted permissions. Additionally, line 57 explicitly chmod 644 after creation is unnecessary overhead.
Consider using a safer pattern:
- name: Write license file for testing
run: |
mkdir -p test-license
- echo "${{ steps.vault-secrets.outputs.ENTERPRISE_LICENSE }}" > test-license/license.lic
- chmod 644 test-license/license.lic
+ echo "${{ steps.vault-secrets.outputs.ENTERPRISE_LICENSE }}" > test-license/license.lic
+ chmod 600 test-license/license.licThe default umask should create files with secure permissions; use 600 (owner read/write only) for sensitive license data instead of 644.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Write license file for testing | |
| run: | | |
| mkdir -p test-license | |
| echo "${{ steps.vault-secrets.outputs.ENTERPRISE_LICENSE }}" > test-license/license.lic | |
| chmod 644 test-license/license.lic | |
| - name: Write license file for testing | |
| run: | | |
| mkdir -p test-license | |
| echo "${{ steps.vault-secrets.outputs.ENTERPRISE_LICENSE }}" > test-license/license.lic | |
| chmod 600 test-license/license.lic |
🤖 Prompt for AI Agents
.github/workflows/test-enterprise.yml lines 53-57: the workflow currently echoes
the vault secret directly which can leak to logs and creates a world-readable
file; instead write the secret using a safe redirection that does not print the
value (e.g. use a here-doc or redirected write that avoids expansion to stdout),
ensure the file is created with restrictive permissions (use umask or create the
file with mode 600) and remove the unnecessary chmod 644; implement creating the
test-license dir, write the license to test-license/license.lic with owner-only
read/write, and do not echo the secret to stdout.
The license file is a binary file, but AWS Secrets Manager stores it as hex dump text. Updated the workflow to convert the hex string to binary: - Use `tr -d ' \n'` to remove spaces and newlines from hex dump - Use `xxd -r -p` to convert hex string to binary data - Added verification logging to show file size after conversion This ensures the .lic file is properly written as binary data rather than as text containing hex characters. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The aws-secretsmanager-get-secrets action with parse-json-secrets sets
the secret as an environment variable, not as a step output. Changed to
reference it via ${{ env.ENTERPRISE_LICENSE }} instead of step output.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The entrypoint script intentionally does NOT change to /liquibase/project to avoid permission issues when Liquibase Enterprise writes daticaldb.log to the current working directory. Updated the test to: - Keep the warning message about working directory not changing - Use absolute path (/liquibase/project/test-file.txt) instead of relative - Update success message to reflect absolute path usage - Update comments to explain the design decision This matches the actual behavior and best practices for the Enterprise image. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
README-enterprise.md (3)
34-43: Add a language identifier to the example output code fence (MD040).The fenced block at Line 34 currently uses plain triple backticks. To satisfy markdownlint (MD040) and improve rendering, give it a language, e.g.:
-**Example output:** -``` +**Example output:** +```text Liquibase Enterprise CLI 8.10 Component Versions: ... -``` +```
325-344: Align Apple Siliconshow versionexample with entrypoint semantics.Earlier examples invoke subcommands directly (
show version,statusDetails DEV, etc.), relying on the entrypoint to route tohammer. The Apple Silicon example switches tohammer show version(Line 334), which may confuse users and could behave differently depending on entrypoint logic.For consistency, either:
- Use
show versionhere as well, or- Explicitly document why Apple Silicon requires
hammer show versionwhile other examples do not.
358-385: Convert emphasized “Example” labels to proper headings (MD036).markdownlint flags Lines 358 and 370 for “emphasis used instead of a heading”. You can keep the same visual intent and satisfy MD036 by turning them into headings, e.g.:
-**Example: Adding PostgreSQL Client** +#### Example: Adding PostgreSQL Client ... -**Example: Adding SQL Server Tools** +#### Example: Adding SQL Server ToolsDockerfileEnterprise (1)
2-10: Confirm choice ofeclipse-temurin:21-jre-noblevs Jammy base image.Both stages use
FROM eclipse-temurin:21-jre-noble(Lines 2 and 54). Existing images in this repo standardize on Eclipse Temurin JRE 21 with Jammy as the base; switching Enterprise to Noble may be intentional, but it diverges from that pattern.Please confirm:
- That Noble is the desired long‑term base for Enterprise, and
- That we’re comfortable having Enterprise on Noble while Community/Secure remain on Jammy (or plan to align them).
If the goal is consistency across images, consider using the Jammy-tagged base here as well.
As per coding guidelines and prior learnings about base image standardization.
Also applies to: 53-55
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
DockerfileEnterprise(1 hunks)README-enterprise.md(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/Dockerfile*
📄 CodeRabbit inference engine (CLAUDE.md)
**/Dockerfile*: When extending Community images, useFROM liquibase/liquibase:latestas the base and add database drivers using LPM (e.g.,lpm add mysql --global)
When extending Secure images, useFROM liquibase/liquibase-secure:latestas the base and setLIQUIBASE_LICENSE_KEYenvironment variable
Files:
DockerfileEnterprise
🧠 Learnings (15)
📓 Common learnings
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Community images, use `FROM liquibase/liquibase:latest` as the base and add database drivers using LPM (e.g., `lpm add mysql --global`)
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,docker-compose.yml} : Docker Community images should use distinct tagging strategy: Git tag format `v{version}` (e.g., `v5.0.1`), GitHub Release labeled `v{version}`, and Docker image tags `liquibase/liquibase:{version}`, `liquibase/liquibase:{major.minor}`, and `liquibase/liquibase:latest`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Community Docker images should be published to Docker Hub as `liquibase/liquibase`, GitHub Container Registry as `ghcr.io/liquibase/liquibase*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase*`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Secure Docker images should be published to Docker Hub as `liquibase/liquibase-secure`, GitHub Container Registry as `ghcr.io/liquibase/liquibase-secure*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase-secure*`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Docker Secure images should use distinct tagging strategy: Git tag format `v{version}-SECURE` (e.g., `v5.0.1-SECURE`), GitHub Release labeled `v{version}-SECURE`, and Docker image tags `liquibase/liquibase-secure:{version}`, `liquibase/liquibase-secure:{major.minor}`, and `liquibase/liquibase-secure:latest`
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Secure images, use `FROM liquibase/liquibase-secure:latest` as the base and set `LIQUIBASE_LICENSE_KEY` environment variable
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to Dockerfile : Community Liquibase versions should be sourced from GitHub releases and controlled via `LIQUIBASE_VERSION` ARG
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set working directory to `/liquibase` in all Docker images
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : When adding tools or runtime dependencies to images, switch to root user, run apt-get operations, and switch back to non-root `liquibase` user in multi-step processes
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Validate Liquibase and LPM binary SHA256 checksums for security in Dockerfile builds
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to docker-entrypoint.sh : Enable automatic changelog directory detection in `docker-entrypoint.sh`: detect `/liquibase/changelog` mount and change working directory for CLI-Docker compatibility, unless `SHOULD_CHANGE_DIR` environment variable explicitly overrides this behavior
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set `liquibase.docker.properties` default configuration file to enable headless mode in all images
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Secure images, use `FROM liquibase/liquibase-secure:latest` as the base and set `LIQUIBASE_LICENSE_KEY` environment variable
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to **/Dockerfile* : When extending Community images, use `FROM liquibase/liquibase:latest` as the base and add database drivers using LPM (e.g., `lpm add mysql --global`)
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Community Docker images should be published to Docker Hub as `liquibase/liquibase`, GitHub Container Registry as `ghcr.io/liquibase/liquibase*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase*`
Applied to files:
README-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,docker-compose.yml} : Docker Community images should use distinct tagging strategy: Git tag format `v{version}` (e.g., `v5.0.1`), GitHub Release labeled `v{version}`, and Docker image tags `liquibase/liquibase:{version}`, `liquibase/liquibase:{major.minor}`, and `liquibase/liquibase:latest`
Applied to files:
README-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Secure Docker images should be published to Docker Hub as `liquibase/liquibase-secure`, GitHub Container Registry as `ghcr.io/liquibase/liquibase-secure*`, and Amazon ECR Public as `public.ecr.aws/liquibase/liquibase-secure*`
Applied to files:
README-enterprise.md
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to Dockerfile : Community Liquibase versions should be sourced from GitHub releases and controlled via `LIQUIBASE_VERSION` ARG
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : When adding tools or runtime dependencies to images, switch to root user, run apt-get operations, and switch back to non-root `liquibase` user in multi-step processes
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Docker Secure images should use distinct tagging strategy: Git tag format `v{version}-SECURE` (e.g., `v5.0.1-SECURE`), GitHub Release labeled `v{version}-SECURE`, and Docker image tags `liquibase/liquibase-secure:{version}`, `liquibase/liquibase-secure:{major.minor}`, and `liquibase/liquibase-secure:latest`
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to DockerfileSecure : Secure Liquibase versions should be sourced from repo.liquibase.com and controlled via `LIQUIBASE_PRO_VERSION` ARG
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set working directory to `/liquibase` in all Docker images
Applied to files:
README-enterprise.mdDockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Create and use non-root `liquibase` user with UID/GID 1001 for running the container
Applied to files:
DockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Set `liquibase.docker.properties` default configuration file to enable headless mode in all images
Applied to files:
DockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Validate Liquibase and LPM binary SHA256 checksums for security in Dockerfile builds
Applied to files:
DockerfileEnterprise
📚 Learning: 2025-11-24T16:48:37.150Z
Learnt from: CR
Repo: liquibase/docker PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:48:37.150Z
Learning: Applies to {Dockerfile,DockerfileSecure,Dockerfile.alpine} : Base image must use Eclipse Temurin JRE 21 (Jammy) as the foundation
Applied to files:
DockerfileEnterprise
🪛 markdownlint-cli2 (0.18.1)
README-enterprise.md
34-34: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
358-358: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
370-370: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🔇 Additional comments (1)
DockerfileEnterprise (1)
12-23: Good use of SHA256 verification and build‑time secret for the license.The builder stage correctly:
- Pins the installer via
ENT_JAR_SHA256and validates it withsha256sum -c(Lines 12–19).- Uses a BuildKit secret for the license (
--mount=type=secret,id=license) and keeps the license ephemeral while runninghammer installDrivers(Lines 47–51).This aligns well with the security guidance around checksum validation and secret handling.
Also applies to: 45-51
| ## 🛠️ Building the Image Locally | ||
|
|
||
| ### Prerequisites | ||
|
|
||
| - Docker or Docker Desktop installed | ||
| - Access to software.datical.com to download the Liquibase Enterprise installer | ||
|
|
||
| ### Build for Your Platform | ||
|
|
||
| ```bash | ||
| # Build for current platform (ARM64 on Apple Silicon, AMD64 on Intel/AMD) | ||
| docker build -f DockerfileEnterprise \ | ||
| --build-arg ENTERPRISE_VERSION=8.10.479 \ | ||
| -t liquibase/liquibase-enterprise:local \ | ||
| . | ||
| ``` | ||
|
|
||
| ### Build for Specific Platform | ||
|
|
||
| ```bash | ||
| # Build for AMD64 (Intel/AMD) - Required for production Linux servers | ||
| docker buildx build --platform linux/amd64 \ | ||
| -f DockerfileEnterprise \ | ||
| --build-arg ENTERPRISE_VERSION=8.10.479 \ | ||
| -t liquibase/liquibase-enterprise:amd64 \ | ||
| --load \ | ||
| . | ||
|
|
||
| # Build for ARM64 (Apple Silicon, ARM servers) | ||
| docker buildx build --platform linux/arm64 \ | ||
| -f DockerfileEnterprise \ | ||
| --build-arg ENTERPRISE_VERSION=8.10.479 \ | ||
| -t liquibase/liquibase-enterprise:arm64 \ | ||
| --load \ | ||
| . | ||
| ``` | ||
|
|
||
| ### Build Multi-Platform Image | ||
|
|
||
| ```bash | ||
| # Build for both AMD64 and ARM64 | ||
| docker buildx build \ | ||
| --platform linux/amd64,linux/arm64 \ | ||
| -f DockerfileEnterprise \ | ||
| --build-arg ENTERPRISE_VERSION=8.10.479 \ | ||
| -t liquibase/liquibase-enterprise:multiarch | ||
| . | ||
| ``` |
There was a problem hiding this comment.
Fix local build instructions: missing license secret and multi‑arch build syntax.
Two issues in the “Building the Image Locally” section:
- Builds require a license secret but examples omit
--secret.
DockerfileEnterpriseusesRUN --mount=type=secret,id=license,target=/tmp/license.lic ...in the builder stage; without passing that secret,hammer installDriverswill fail. Please update all build examples to include a license secret, e.g.:
-docker build -f DockerfileEnterprise \
- --build-arg ENTERPRISE_VERSION=8.10.479 \
- -t liquibase/liquibase-enterprise:local \
- .
+DOCKER_BUILDKIT=1 docker build \
+ --secret id=license,src=/path/to/license.lic \
+ -f DockerfileEnterprise \
+ --build-arg ENTERPRISE_VERSION=8.10.479 \
+ -t liquibase/liquibase-enterprise:local \
+ .and similarly for the docker buildx build AMD64/ARM64 and multi‑platform examples.
- Multi‑platform example is syntactically broken.
In the “Build Multi‑Platform Image” snippet, the final.is on a new line but the preceding line (Line 219) is missing a trailing\, so.runs as a separate shell command instead of the build context:
--build-arg ENTERPRISE_VERSION=8.10.479 \
- -t liquibase/liquibase-enterprise:multiarch
- .
+ -t liquibase/liquibase-enterprise:multiarch \
+ .Consider also adding --push or --load so users get a usable image from buildx.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In README-enterprise.md around lines 174 to 221, the local build examples omit
the license secret and the multi-platform snippet has a broken line
continuation; update every docker build and docker buildx build example to
include the secret flag referencing the license used by DockerfileEnterprise
(e.g. add --secret id=license,src=/path/to/license.lic or the buildx
equivalent), fix the multi-platform example so the final tag line ends with a
trailing backslash before the context dot (so the dot stays on the same command
line), and add either --load or --push to the buildx multi-arch command so the
produced image is usable locally or pushed to a registry.
- Install git and openssh-client for Packager SCM workflows - Set default git identity and safe.directory for mounted volumes - Add mssql_driver.properties with default MSSQL JDBC settings - Set WORKDIR to /liquibase/project for easier project access - Update entrypoint to configure SSH known_hosts automatically - Update tests and README for git, SSH, and MSSQL configuration Add git, SSH, and default MSSQL config to Enterprise image - Install git and openssh-client for Packager SCM workflows - Set default git identity and configure safe.directory for Docker - Add default mssql_driver.properties for SQL Server connectivity - Update WORKDIR to /liquibase/project for project file access - Document new features and usage in README-enterprise.md - Update entrypoint to auto-configure SSH known_hosts for common providers - Enhance test workflow to verify git installation and working directory
- Allow mounting SSH keys to /liquibase/.ssh-mount for use in container - Automatically copy keys and set correct permissions at startup - Update README-enterprise.md with SSH key and agent usage instructions
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In @.github/workflows/test-enterprise.yml:
- Around line 72-74: The GitHub Actions build step "Build Enterprise image from
DockerfileEnterprise" fails because DockerfileEnterprise uses RUN
--mount=type=secret,id=license to provide a license for hammer installDrivers;
modify that workflow step to pass the secret via --secret
id=license,src=<path-to-license-file> (or reference GitHub Actions secrets with
actions/setup-docker/secret mechanism) so the secret mount is populated during
docker build, ensuring hammer installDrivers can access the license; target the
build step that runs docker build -f DockerfileEnterprise and add the
appropriate --secret argument.
- Around line 204-214: The docker run volume mounts in the test workflow use
unquoted $(pwd) which can break on paths with spaces; update each docker run -v
invocation (the ones that set RESULT via docker run and any other runs in this
file) to use a quoted working directory like "$(pwd)" in the -v argument so the
shell preserves spaces (e.g., change -v $(pwd)/test-license:/liquibase/license
to -v "$(pwd)"/test-license:/liquibase/license), and apply the same quoting to
all similar occurrences that set RESULT or run containers (ensure EXIT_CODE
handling remains unchanged).
In `@docker-entrypoint-enterprise.sh`:
- Around line 17-26: The current startup logic uses type "$1" to decide whether
to exec the OS command which can misroute hammer subcommands (e.g., diff, test)
to system binaries; replace the type-based test with an explicit allowlist check
and a check for absolute/path-invocation: build an array (e.g., ALLOWED_CMDS) of
real shell commands that should bypass hammer (bash, sh, cat, ls, tail,
/bin/..., etc.), test membership of "$1" against that list, and also treat
arguments starting with "/" as direct executables; keep the special-case for
"history" and the existing handling for a leading "hammer" (shift + exec hammer
"$@") so only allowlisted or absolute paths are exec'd directly and all other
first-args are forwarded to hammer.
In `@DockerfileEnterprise`:
- Around line 20-22: Add an ARG for the expected SHA256 of the
DaticalDBCompositeRepo zip (similar to the installer JAR arg), download the zip
as currently done (DaticalDBCompositeRepo-${ENTERPRISE_VERSION}.zip) and
immediately verify it with sha256sum -c using the ARG value; if the checksum
fails, ensure the build exits non‑zero (mirror the existing installer validation
pattern) so the composite repo download cannot proceed without matching the
provided SHA256.
In `@README-enterprise.md`:
- Line 582: The sentence fragment ending "...such as Bash, etc from the base
distribution" is missing the period after the abbreviation "etc"; update that
exact text to read "etc. from the base distribution" so the abbreviation follows
American English punctuation conventions (modify the line containing "such as
Bash, etc from the base distribution, along with any direct or indirect
dependencies..." to insert the period after "etc").
- Around line 34-43: The README-enterprise.md example output shows "Java
11.0.15" which conflicts with the Dockerfile base image
(eclipse-temurin:21-jre-noble); update the README by adding a single-sentence
clarification after the "hammer show version" example stating that the
Enterprise runtime bundles its own JRE 11 internally while the container image
uses Java 21 for the host, and change the fenced code block to specify a
language (e.g., ```text) to satisfy markdownlint MD040; reference the "hammer
show version" output block and the Dockerfile base image name when making the
edit.
🧹 Nitpick comments (3)
mssql_driver.properties (1)
4-5:trustServerCertificate=trueweakens TLS guarantees in production.With
encrypt=trueandtrustServerCertificate=true, connections use TLS but skip server certificate validation, making them vulnerable to MITM attacks. This is a pragmatic default for getting started, but the README and comments should more prominently warn users to override this withtrustServerCertificate=false(and a proper trust store) for production deployments.DockerfileEnterprise (1)
67-68:safe.directory '*'grants git trust to every directory on the system.While this is a common Docker pattern, it disables git's ownership safety check entirely. If the container is ever used in a context where untrusted directories could be mounted, this could allow git operations on adversary-controlled repos. Consider scoping to just the known mount points:
-RUN git config --system --add safe.directory '*' && \ +RUN git config --system --add safe.directory /liquibase/project && \docker-entrypoint-enterprise.sh (1)
11-14: SSH known_hosts population runs on every container start.
ssh-keyscanmakes network calls to github.com, gitlab.com, bitbucket.org, and ssh.dev.azure.com on every container startup whenSSH_AUTH_SOCKis set andknown_hostsdoesn't yet exist. Since the volume is ephemeral by default, this will run on nearly every invocation, adding latency and a network dependency to startup. The|| truemeans a network failure is silent, but the user gets noknown_hostsand SSH will fail later with a confusing host-key error.Consider baking the known host keys into the image at build time instead, so there's no runtime network dependency.
| - name: Build Enterprise image from DockerfileEnterprise | ||
| run: | | ||
| docker build -f DockerfileEnterprise -t liquibase/liquibase-enterprise:${{ github.sha }} . |
There was a problem hiding this comment.
Build will fail: --secret not passed but required by DockerfileEnterprise.
DockerfileEnterprise line 47 uses RUN --mount=type=secret,id=license,... for driver installation. Without --secret id=license,src=... in the build command, the mount will be empty and hammer installDrivers will fail.
- docker build -f DockerfileEnterprise -t liquibase/liquibase-enterprise:${{ github.sha }} .
+ DOCKER_BUILDKIT=1 docker build \
+ --secret id=license,src=$(pwd)/test-license/license.lic \
+ -f DockerfileEnterprise \
+ -t liquibase/liquibase-enterprise:${{ github.sha }} \
+ .📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Build Enterprise image from DockerfileEnterprise | |
| run: | | |
| docker build -f DockerfileEnterprise -t liquibase/liquibase-enterprise:${{ github.sha }} . | |
| - name: Build Enterprise image from DockerfileEnterprise | |
| run: | | |
| DOCKER_BUILDKIT=1 docker build \ | |
| --secret id=license,src=$(pwd)/test-license/license.lic \ | |
| -f DockerfileEnterprise \ | |
| -t liquibase/liquibase-enterprise:${{ github.sha }} \ | |
| . |
🤖 Prompt for AI Agents
In @.github/workflows/test-enterprise.yml around lines 72 - 74, The GitHub
Actions build step "Build Enterprise image from DockerfileEnterprise" fails
because DockerfileEnterprise uses RUN --mount=type=secret,id=license to provide
a license for hammer installDrivers; modify that workflow step to pass the
secret via --secret id=license,src=<path-to-license-file> (or reference GitHub
Actions secrets with actions/setup-docker/secret mechanism) so the secret mount
is populated during docker build, ensuring hammer installDrivers can access the
license; target the build step that runs docker build -f DockerfileEnterprise
and add the appropriate --secret argument.
| - name: Test entrypoint script | ||
| run: | | ||
| echo "Testing entrypoint script functionality..." | ||
|
|
||
| # Test that entrypoint executes hammer by default with valid license | ||
| # Note: We mount the license file to test the full workflow | ||
| set +e | ||
| RESULT=$(docker run --rm \ | ||
| -v $(pwd)/test-license:/liquibase/license \ | ||
| liquibase/liquibase-enterprise:${{ github.sha }} --help 2>&1) | ||
| EXIT_CODE=$? |
There was a problem hiding this comment.
Quote $(pwd) to prevent word splitting with paths containing spaces.
Multiple docker run -v $(pwd)/... invocations throughout the workflow are unquoted. This is flagged by shellcheck (SC2046). Use "$(pwd)" consistently.
- -v $(pwd)/test-license:/liquibase/license \
+ -v "$(pwd)/test-license":/liquibase/license \This applies to all similar occurrences at lines 212, 249, 273, 299, 314, and 352.
🧰 Tools
🪛 actionlint (1.7.10)
[error] 205-205: shellcheck reported issue in this script: SC2046:warning:7:6: Quote this to prevent word splitting
(shellcheck)
🤖 Prompt for AI Agents
In @.github/workflows/test-enterprise.yml around lines 204 - 214, The docker run
volume mounts in the test workflow use unquoted $(pwd) which can break on paths
with spaces; update each docker run -v invocation (the ones that set RESULT via
docker run and any other runs in this file) to use a quoted working directory
like "$(pwd)" in the -v argument so the shell preserves spaces (e.g., change -v
$(pwd)/test-license:/liquibase/license to -v
"$(pwd)"/test-license:/liquibase/license), and apply the same quoting to all
similar occurrences that set RESULT or run containers (ensure EXIT_CODE handling
remains unchanged).
| if [[ "$1" != "history" ]] && type "$1" > /dev/null 2>&1; then | ||
| # First argument is an actual OS command. Run it directly | ||
| exec "$@" | ||
| else | ||
| # Default to hammer commands for Liquibase Enterprise | ||
| # If first argument is 'hammer', remove it since we're calling hammer anyway | ||
| if [ "$1" = "hammer" ]; then | ||
| shift | ||
| fi | ||
| exec hammer "$@" |
There was a problem hiding this comment.
Command routing can misroute hammer subcommands that match OS command names.
type "$1" succeeds for any shell builtin or OS binary. Besides the already-special-cased history, hammer subcommands like diff, test, or snapshot could collide with /usr/bin/diff, shell builtin test, etc., and be executed as OS commands instead of being forwarded to hammer.
A safer approach is to maintain an explicit allowlist of commands that should bypass hammer (e.g., bash, sh, cat, ls, etc.) or check whether $1 starts with a / or is in a known set of OS utilities.
Example: allowlist approach
-if [[ "$1" != "history" ]] && type "$1" > /dev/null 2>&1; then
- # First argument is an actual OS command. Run it directly
- exec "$@"
+# Commands that should bypass hammer and execute directly
+PASSTHROUGH_CMDS="bash sh cat ls env printenv id whoami pwd java git ssh"
+
+is_passthrough() {
+ for cmd in $PASSTHROUGH_CMDS; do
+ [ "$1" = "$cmd" ] && return 0
+ done
+ return 1
+}
+
+if is_passthrough "$1"; then
+ exec "$@"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if [[ "$1" != "history" ]] && type "$1" > /dev/null 2>&1; then | |
| # First argument is an actual OS command. Run it directly | |
| exec "$@" | |
| else | |
| # Default to hammer commands for Liquibase Enterprise | |
| # If first argument is 'hammer', remove it since we're calling hammer anyway | |
| if [ "$1" = "hammer" ]; then | |
| shift | |
| fi | |
| exec hammer "$@" | |
| # Commands that should bypass hammer and execute directly | |
| PASSTHROUGH_CMDS="bash sh cat ls env printenv id whoami pwd java git ssh" | |
| is_passthrough() { | |
| for cmd in $PASSTHROUGH_CMDS; do | |
| [ "$1" = "$cmd" ] && return 0 | |
| done | |
| return 1 | |
| } | |
| if is_passthrough "$1"; then | |
| exec "$@" | |
| else | |
| # Default to hammer commands for Liquibase Enterprise | |
| # If first argument is 'hammer', remove it since we're calling hammer anyway | |
| if [ "$1" = "hammer" ]; then | |
| shift | |
| fi | |
| exec hammer "$@" |
🤖 Prompt for AI Agents
In `@docker-entrypoint-enterprise.sh` around lines 17 - 26, The current startup
logic uses type "$1" to decide whether to exec the OS command which can misroute
hammer subcommands (e.g., diff, test) to system binaries; replace the type-based
test with an explicit allowlist check and a check for absolute/path-invocation:
build an array (e.g., ALLOWED_CMDS) of real shell commands that should bypass
hammer (bash, sh, cat, ls, tail, /bin/..., etc.), test membership of "$1"
against that list, and also treat arguments starting with "/" as direct
executables; keep the special-case for "history" and the existing handling for a
leading "hammer" (shift + exec hammer "$@") so only allowlisted or absolute
paths are exec'd directly and all other first-args are forwarded to hammer.
| # Download CompositeRepo containing database drivers | ||
| RUN wget -q -O DaticalDBCompositeRepo.zip \ | ||
| "https://software.datical.com/Datical_DB_Software/Datical_DB_${ENTERPRISE_VERSION}/DaticalDBCompositeRepo-${ENTERPRISE_VERSION}.zip" |
There was a problem hiding this comment.
CompositeRepo zip download lacks SHA256 verification.
The installer JAR is checksum-verified (line 18), but the DaticalDBCompositeRepo.zip is downloaded without any integrity check. This is inconsistent and leaves a gap where a tampered driver bundle could be injected.
Add a ARG + sha256sum -c check mirroring the pattern used for the installer JAR.
Proposed fix
+ARG COMPOSITE_REPO_SHA256=<insert_hash_here>
+
# Download CompositeRepo containing database drivers
RUN wget -q -O DaticalDBCompositeRepo.zip \
- "https://software.datical.com/Datical_DB_Software/Datical_DB_${ENTERPRISE_VERSION}/DaticalDBCompositeRepo-${ENTERPRISE_VERSION}.zip"
+ "https://software.datical.com/Datical_DB_Software/Datical_DB_${ENTERPRISE_VERSION}/DaticalDBCompositeRepo-${ENTERPRISE_VERSION}.zip" && \
+ echo "$COMPOSITE_REPO_SHA256 *DaticalDBCompositeRepo.zip" | sha256sum -c -Based on learnings: "Validate Liquibase and LPM binary SHA256 checksums for security in Dockerfile builds"
🤖 Prompt for AI Agents
In `@DockerfileEnterprise` around lines 20 - 22, Add an ARG for the expected
SHA256 of the DaticalDBCompositeRepo zip (similar to the installer JAR arg),
download the zip as currently done
(DaticalDBCompositeRepo-${ENTERPRISE_VERSION}.zip) and immediately verify it
with sha256sum -c using the ARG value; if the checksum fails, ensure the build
exits non‑zero (mirror the existing installer validation pattern) so the
composite repo download cannot proceed without matching the provided SHA256.
| ``` | ||
| Liquibase Enterprise CLI 8.10 | ||
| Component Versions: | ||
| Liquibase Enterprise Core 8.10.479 | ||
| Liquibase Enterprise CLI 8.10.479.20250717040249 | ||
| Liquibase 3.5.11640 | ||
| Stored Logic extension 1.0.318.20250710062909 | ||
| AppDBA extension 1.0.474.20250710061826 | ||
| Java 11.0.15 | ||
| ``` |
There was a problem hiding this comment.
Example output shows Java 11 but the image ships Java 21 — potentially confusing.
The example version output shows Java 11.0.15, but the Dockerfile uses eclipse-temurin:21-jre-noble. Users may wonder why java -version reports 21 but hammer show version reports Java 11. If the Enterprise runtime bundles its own JRE 11 internally, add a brief note clarifying this distinction. Also, the fenced code block at line 34 should specify a language (e.g., text) per markdownlint MD040.
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 34-34: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@README-enterprise.md` around lines 34 - 43, The README-enterprise.md example
output shows "Java 11.0.15" which conflicts with the Dockerfile base image
(eclipse-temurin:21-jre-noble); update the README by adding a single-sentence
clarification after the "hammer show version" example stating that the
Enterprise runtime bundles its own JRE 11 internally while the container image
uses Java 21 for the host, and change the fenced code block to specify a
language (e.g., ```text) to satisfy markdownlint MD040; reference the "hammer
show version" output block and the Dockerfile base image name when making the
edit.
|
|
||
| View [license information](https://www.datical.com/eula) for the software contained in this image. | ||
|
|
||
| As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained). |
There was a problem hiding this comment.
Minor: missing period after "etc".
Per American English conventions, abbreviations like "etc." require a period.
-(such as Bash, etc from the base distribution,
+(such as Bash, etc. from the base distribution,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained). | |
| As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc. from the base distribution, along with any direct or indirect dependencies of the primary software being contained). |
🧰 Tools
🪛 LanguageTool
[style] ~582-~582: In American English, abbreviations like “etc.” require a period.
Context: ... be under other licenses (such as Bash, etc from the base distribution, along with ...
(ETC_PERIOD)
🤖 Prompt for AI Agents
In `@README-enterprise.md` at line 582, The sentence fragment ending "...such as
Bash, etc from the base distribution" is missing the period after the
abbreviation "etc"; update that exact text to read "etc. from the base
distribution" so the abbreviation follows American English punctuation
conventions (modify the line containing "such as Bash, etc from the base
distribution, along with any direct or indirect dependencies..." to insert the
period after "etc").
1 participant
Summary
Implements production-ready Docker image for Liquibase Enterprise (formerly Datical DB) with comprehensive testing, automation, and documentation.
Key Components
🐳 Docker Implementation
DockerfileEnterprise
autoInstall.xml
docker-entrypoint-enterprise.sh
/liquibase/license/DATDB_LICENSEenvironment variable/liquibase/projectdirectory📚 Documentation
README-enterprise.md
docker-compose.enterprise.yml
🚀 GitHub Actions Workflows
create-release-enterprise.yml
v{version}-ENTERPRISEformattest-enterprise.yml
trivy-enterprise.yml
✅ Testing & Verification
DATDB_LICENSE) workingArchitecture Decisions
Separate Workflows: Enterprise uses dedicated workflows (not added to test.yml/trivy.yml matrix) because:
hammervsliquibase)Tag Format:
v{version}-ENTERPRISEprevents conflicts with Community (v{version}) and Secure (v{version}-SECURE)License Handling: Runtime mounting (not build-time) for security and flexibility
Platform Support: Multi-arch build with Apple Silicon documentation (
--platformflag)Available Registries
Images will be published to:
liquibase/liquibase-enterpriseghcr.io/liquibase/liquibase-enterprisepublic.ecr.aws/liquibase/liquibase-enterpriseFiles Changed
.github/workflows/create-release-enterprise.yml- Release automation.github/workflows/test-enterprise.yml- Comprehensive testing.github/workflows/trivy-enterprise.yml- Security scanningDockerfileEnterprise- Multi-stage buildREADME-enterprise.md- Complete documentationautoInstall.xml- IzPack configurationdocker-entrypoint-enterprise.sh- Entrypoint scriptexamples/docker-compose/docker-compose.enterprise.yml- Docker Compose exampleCloses DAT-7679
🤖 Generated with Claude Code