action #88451
closed
Static validation for containers
Added by livdywan over 3 years ago.
Updated over 3 years ago.
Category:
Feature requests
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¶
- Target version set to Ready
- Target version changed from Ready to future
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
ilausuch wrote:
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
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.
- 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.
- Blocks action #76978: How to run an openQA test in 5 minutes size:M added
- Status changed from Workable to Feedback
- Assignee set to okurz
- Target version changed from future to Ready
- Due date set to 2021-03-16
- Status changed from Feedback to Resolved
Also available in: Atom
PDF