elgohr / Publish-Docker-Github-Action

A Github Action used to build and publish Docker images
MIT License
781 stars 209 forks source link

chore: Improve Dockerfile #197

Closed reneleonhardt closed 6 months ago

reneleonhardt commented 7 months ago

Image builds faster and smaller, fixed some Dockerfile warnings and 166 security findings 😅 Please double-check if everything is still working as expected (I removed docker-compose) and release a new image.

Consider rebuilding the image automatically with something like https://github.com/aquasecurity/trivy-action and migrating to alpine, should be smaller and have less dependencies (docker also installs engine, cli and buildx). https://pkgs.alpinelinux.org/packages?name=docker*&branch=v3.19&repo=community&arch=x86_64

elgohr commented 6 months ago

Thank you for the PR! Will review in near future

elgohr commented 6 months ago

I'm thinking about declining the PR.

The Dockerfile is used in context of testing the action within CI/CD. The image will never be in production, but be gone after testing.

There're a few docker optimizations still in place, from a time where this action shipped the image to production. This isn't the case anymore, so the optimizations could also be removed in future.

As the image isn't shipped, the size of the image isn't relevant at all.

Security findings and speed would be an improvement for the release process.

Nevertheless the changes add more complexity to the build process of the image.

I have to check the speed improvement this would add.

Where did you get the security findings that you had been writing about?

reneleonhardt commented 6 months ago

It's used in release.yml, 168 findings today, too many packages installed and too rarely updated (Docker shows 8 months old jammy-20230816).

docker pull vuln ghcr.io/elgohr/publish-docker-github-action/publish-docker-github-action
trivy image --scanners vuln ghcr.io/elgohr/publish-docker-github-action/publish-docker-github-action
publish-docker-github-action jammy-20230816
elgohr commented 6 months ago

Alright I totally got that for production related images. For testing images these findings seem odd.

elgohr commented 6 months ago

I measured it multiple times - the image builds at my machine in around 1:15 min. Main tends to be a little quicker (1:10 - 1:15 min). Ironically the PR seems to be slower (1:15-1:20 min). So this is no reason.

In addition the screenshot of the vulnerabilities shows an image that was created 8 month ago (see top of screenshot). In this way an 8 month old jammy is no surprise.

I'm really happy that you tried to improve the action! Nevertheless I'm going to reject the PR as I'm not seeing the desired improvement - sorry! Next time please start with an issue, so we don't come to the point to throw away time/code again.