Dockerfile

[nvanheuverzwijn]

Description
This pull request adds a scratch docker image with a statically built (GO version 1.14) webhook binary without debug information.

Features

• Add support for LDFLAGS in the makefile.
• Add a scratch Dockerfile to acheive a very small image.

Notes

• .dockerignore includes only needed files when executing docker build.
• CGO_ENABLED=0 removes cgo usage and compile C library into GO binary.
• LDFLAGS="-w -s" removes debug information.

[nvanheuverzwijn]

@adnanh This add a from scratch dockerfile. I will add github actions in another PR.

[chris13524]

I'm using this alternative while waiting for this.

[nvanheuverzwijn]

@chris13524 I wanted to use this project with kubernetes but I found argo-events (https://argoproj.github.io/argo-events/) which is something a little bit more kubernetes friendly.
There's an upstream container and a helm-chart managed by the community.
I don't expect this PR to be merged anytime soon because it's been more than one month old and it does add some kind of mangement overhead. We only have a limited amount of time per day and these open source project do take a lot of time sometimes.

[moorereason]

Speaking for myself: I don't use k8s and rarely use Docker, so with limited time and knowledge, I'm not in a position to support them.

[adnanh]

+1 to what @moorereason said, you can create a separate repo for this and I can link from the README if you want?

[pwillis-els]

I'm not sure I understand why one would reject a contribution like this if it doesn't affect you. You don't use Docker or K8s, that's fine... it means merging it will not break anything you currently do. But it would help your users.

Maintaining the Dockerfile in a separate repo and linking to it by your docs is needlessly adding complexity. If it's not maintained by you, it may not receive updates that might be needed ("out of sight, out of mind"). And that also means your team won't own the Docker Hub images, so people concerned with security won't use them, and will have to build/maintain their own containers. This means there is no "off the shelf" component, which makes it less likely people will use it (esp. professionally).

You don't even have to support Docker in your project. You can just keep the Dockerfile in your repo, and hook up Docker Hub automatic builds. You can then reject any issues/PRs relating to Docker and explain that it's unsupported, and ask for volunteers to maintain the Dockerfile (which is trivial to do using a CODEOWNERS file). In this way the user community can support it themselves, and it won't take up your time.

Does it take a small amount of time to set this stuff up? Yes. But it ensures that your project's community grows, it's just a nice thing to do for people, and it shouldn't cost you anything long term. Docker/K8s aren't going away any time soon, so this is useful functionality that it seems lots of people are asking for.

I would be happy to walk you through hooking up the docker hub automatic builds, CODEOWNERS file, Issue/PR template, automatic reply bots, and answer any other questions you may have.