Allow exclude section to point at existing ignore file

[nickhammond]

Description

Most container-based applications already have a .dockerignore, it'd be great to be able to point to one of these files for the exclude section of your project descriptor.

Proposed solution

1. Add a file-based reference to the exclude section, something like:

exclude_list = ".dockerignore"

2. Potentially add a CLI option --exclude_list .dockerignore

Either option would read .dockerignore and utilize that as the exclude option for the pack instead of listing them out.

Describe alternatives you've considered

1. Open .dockerignore
2. Copy entire file contents
3. Create project.toml with base spec and an exclude section
4. Within the exclude section paste in the lines from your .dockerignore file
5. Remove all comments and empty lines
6. Quote each line and turn into a proper array of directives so that it looks something like this:

[io.buildpacks]
exclude = [
  "/.git/",
  ".env"
]

9. Remember to maintain two ignore/exclude lists, the one in project.toml and the other one in .dockerignore

Additional context

• project.toml docs

[jjbustamante]

Thinking about this feature, the challenge is the semantics of those ignored files are the same. Searching a little bit I found the following:

Relative Path

In .gitignore, a relative path (e.g. filename) matches the path under any directory;

while in .dockerignore, a relative path (e.g. filename) is the same as a rooted one (e.g. /filename) and matches only ones under the root. To match the path under any directory, **/filename should be used.

Files Under Ignored Path

In .gitignore, if a path is listed as ignored (e.g. /dir), then any files or folders under that path is ignored and it is not possible to re-include them via negation (e.g. !/dir/file) as the parent directory of them is excluded;

while in .dockerignore, even if a parent path is ignored, files or folders under it can still be re-included via negation.

In case where pack takes .dockerignore or .gitignore as input, would we need to implement a different parser for both to handle the semantic of rules of each of them?

[nickhammond]

@jjbustamante I think the focus should just be on .dockerignore since that's what Docker supports and looks for out of the box https://docs.docker.com/build/concepts/context/#dockerignore-files.

I've removed the mention of .gitignore from the description.

[jjbustamante]

@jjbustamante I think the focus should just be on .dockerignore since that's what Docker supports and looks for out of the box https://docs.docker.com/build/concepts/context/#dockerignore-files.

I've removed the mention of .gitignore from the description.

Thanks!

But now checking our documentation

Note the include and exclude sections in the below project.toml file use gitignore syntax. So "/README.md" excludes the README file at the root of the application. For more on gitignore matching see these docs.

Maybe we need to define which syntax from .dockerignore we will implement and which not

[nickhammond]

@jjbustamante That's fun.

I mean I suppose since project.toml uses .gitignore syntax it could just use the same matching for this. Not as obvious but it seems like it'd be more confusing to omit certain matching rules to try to make the .dockerignore matching rules work.

It's also a more straightforward transition if you decide to move your exclude rules from your project.toml to their own file.