Scaffold a dockerignore file

[jgustie]

I've noticed that Docker build context can be significantly larger then necessary; this isn't a huge problem but it can be noticeable at times. Scaffolding a .dockerignore file was previously suggested, but in the context of eliminating COPY statements (which negatively impacts the build cache); this is more about just reducing the build context size.

I am currently using a .dockerignore similar to this in my projects to ensure only the Go code is included in the build context (although just ignoring /bin and /.git can make a big difference):

**
!/api
!/controllers
!/go.mod
!/go.sum
!/main.go

/kind feature

[DirectXMan12]

/help

Sounds like a good plan

[k8s-ci-robot]

@DirectXMan12:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Sounds like a good plan

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Adirio]

**
!/api
!/controllers
!/go.mod
!/go.sum
!/main.go

Adding !/apis would be required for multi-group support.

Which should be the approach related to backwards compatibility? Previously scaffolded projects will not have this file. Are we ok with that? Would this have to wait for v3?
Should we target v2 only or also v1? The file would be slightly different.

[DirectXMan12]

it's generally safe to introduce new files in an existing version if they're scaffolded on initial scaffold, I think. We just can't later assume that file will always be there. Not sure if that's sane from maintainability, but I think its safe compat-wise.

Could we do **/*.go? That covers most things, and then if people have Go in a hack directory, they can always edit this?

This kinda thing makes me really appreciate Bazel's ability to actually track dependencies...

[camilamacedo86]

/assign @camilamacedo86