action #88451
closedStatic validation for containers
Description
Motivation¶
From #80520#note-19:
- Same as in os-autoinst run static style checks on Dockerfiles within PR checks and run build+run steps when running on master, compare to https://github.com/os-autoinst/os-autoinst/pull/1602
Acceptance criteria¶
- AC1: web UI container is statically validated in every PR
- AC2: worker container is statically validated in every PR
Suggestions¶
Updated by ilausuch almost 4 years ago
Hi,
I did an investigation about check dockerfiles and docker-compose files. These are the conclusions
To check the Dockerfile I fond and tested (https://github.com/hadolint/hadolint) This works within a container so we don't need to install extra things
docker run --rm -i hadolint/hadolint <Dockerfile
To check a docker-compose file the best option is to trust the docker-compose itself
docker-compose config
Updated by livdywan almost 4 years ago
ilausuch wrote:
Hi,
I did an investigation about check dockerfiles and docker-compose files. These are the conclusionsTo check the Dockerfile I fond and tested (https://github.com/hadolint/hadolint) This works within a container so we don't need to install extra things
docker run --rm -i hadolint/hadolint <Dockerfile
To check a docker-compose file the best option is to trust the docker-compose itself
There is hadolint on GHA. Although on os-autoinst we have a custom setup with a shellscript.
I kinda like actions that we can use as-is so we don't have to add more custom scripts - but we may want to document the reproducer i.e. the command you gave above since it should be as easy as possible to verify things locally if something fails in CI.
docker-compose config
I would lean towards running compose up
and adding health checks. @ilausuch confirmed in chat that the static checks are always executed there, too.
Updated by livdywan almost 4 years ago
- Status changed from New to Workable
I realize it's not on our backlog but as we're discussing other work, the draft was quick enough to come up with so I proposed it:
https://github.com/os-autoinst/openQA/pull/3761
Which should then decide, though, which of the options we want. But if we don't want this, also fine, it didn't take me long to come up with.
Updated by okurz almost 4 years ago
- Blocks action #76978: How to run an openQA test in 5 minutes size:M added
Updated by okurz almost 4 years ago
- Status changed from Workable to Feedback
- Assignee set to okurz
- Target version changed from future to Ready
Yes, we discussed it in light of the existing tickets on the backlog which we have troubles to complete so we should try this here first to have better checks:
Updated by okurz almost 4 years ago
- Due date set to 2021-03-16
https://github.com/os-autoinst/openQA/pull/3772 merged. I would like to see successful results reported based on master or another PR, not just the checks within my fork, before closing this done.
Updated by okurz almost 4 years ago
- Status changed from Feedback to Resolved
https://github.com/os-autoinst/openQA/runs/2093111665?check_suite_focus=true shows a successful run on master branch.