Open kisst opened 3 months ago
It is easy to run LZA-Validator in action. Here is a example:
Build a LZA-Validator image then push it to your image repo (e.g DockerHub).
Add following to .github/workflow/ folder, e.g validate-lza-config.yml.
name: Validate LZA Configurations
on: push
jobs:
validation:
runs-on: ubuntu-latest
steps:
- name: Checkout LZA configurations repo
uses: actions/checkout@v4
# - name: Login to Docker Hub (required for private)
# uses: docker/login-action@v3
# with:
# username: ${{ secrets.DOCKERHUB_USERNAME }}
# password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Run LZA-Validator
uses: addnab/docker-run-action@v3
with:
image: <your_dockerhub_repo>/lza-validator:<tag>
options: -v ${{ github.workspace }}:/lza/config
run: /lza/lza-validator.sh /lza/config/
Test and verified in my sandbox:
BTW, you can use LZA-RepoSync to sync LZA configuration repositories from GitHub, GitLab, Bitbucket to CodeCommit automatically.
I agree with you that it is easy to run only if we disregard the maintenance of the docker image , however GitHub Actions is a convinient abstraction layer on top of otherwise multistep config, but even just building Docker Images would make a difference , either within GH or at Docker Hub
Unfortunately, we don't have an image repo for that. You can easily create an action to manage your LZA-Validator image build and publish.
How about the GitHub registry itself ? https://docs.github.com/en/actions/publishing-packages/publishing-docker-images#publishing-images-to-github-packages
While the default location for the LZA config is Codepipeline, due the shortfalls for the AWS DevOps tool-chain some LZA customers manage their codebase outside the AWS echo system in some more mature offerings like GH, and as validation should happen also close to the code, GitHub Actions is an obvious choice for this. While the SSM parameter resolution is a limiting factor, via OIDC should be trivial to address too.