Project

General

Profile

action #88451

Static validation for containers

Added by cdywan 2 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-02-04
Due date:
2021-03-16
% Done:

0%

Estimated time:
Difficulty:

Description

Motivation

From #80520#note-19:

  1. 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


Related issues

Blocks openQA Project - action #76978: How to run an openQA test in 5 minutesBlocked2020-11-04

History

#1 Updated by okurz 2 months ago

  • Target version set to Ready

#2 Updated by okurz 2 months ago

  • Target version changed from Ready to future

#3 Updated by ilausuch about 1 month 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

#4 Updated by cdywan about 1 month ago

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.

#5 Updated by cdywan about 1 month 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.

#6 Updated by okurz about 1 month ago

  • Blocks action #76978: How to run an openQA test in 5 minutes added

#7 Updated by okurz about 1 month 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:

https://github.com/os-autoinst/openQA/pull/3772

#8 Updated by okurz about 1 month 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.

#9 Updated by okurz about 1 month ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF