-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement parameters to pass custom ignore file #1325
base: main
Are you sure you want to change the base?
Implement parameters to pass custom ignore file #1325
Conversation
This means these files behave differently from all other configuration files. Do you think these are important enough that repo2docker should support special overrides and merging behaviour? Should something similar be considered for other files e.g. so an admin can set the default python/R version if it's not specified in a repo, or install some extra default packages like UI extensions or other utilities for local use? Should we add some callable hooks instead that allow full modification of the build context before building (and perhaps similar hooks at other stages)? |
You are bringing very good questions. In my original idea I had essentially BinderHub in mind and the optimization of the image building process. For example, avoid generating a big context with files considered useless and improve cache use (in the case of git cloning, no two clones are the same because the content of Your other suggestions sound interesting as well and the hooks would likely be a better fit or to keep things simple maybe a pre-build script ? There's one thing though, the |
The hook would be a pre-build hook called whilst constructing the build context (maybe at the start, just before creating the tar?). It would there have the full ability to add/remove/change files, whether that deleting unwanted files, adding a default version if not set, or modifying environment.yml. Since the hook is a callable it would be defined in a repo2docker config file rather than a repo2docker command line arg, but in this particular case you need to pass the custom ignore file anyway that's not a problem. |
I am not sure to follow you properly. Do you have something like this in mind ?
? |
In supplement to the support for the .dockerignore and .containerignore files, these two new parameters (extra-ignore-file and ingore-file-strategy) allow to modify how the ignore list is managed. This allows, for example in the case of BinderHub, the administrator to have a default set of files or folders that get ignored if the repository does not contain such any ignore file. The following strategies are available: - ours - theirs - merge The first forces the use of the file passed in parameters The second uses the file from the repository if it exists The last puts both together
This is a bit fragile as the path given here should be related to where pytest is called.
e0b1bab
to
ecdcf9e
Compare
Handling of the
.dockerignore
and.containerignore
files is implemented in #1205, however, these files require people to prepare their projects with some knowledge of how they work and thus knowledge of docker/podman. The command parameters added in this PR allows the person responsible to build the image to provide an ignore file so that classic projects do not need one.This can be useful for example on BinderHub. The administrator can provide sensible defaults if there is no ignore file present in the repository being built or force the use of a standard one.
The implementation provide three strategies:
Where merge, as the name suggest will put together the content of the two files, ours will force the use of the file passed in parameter and theirs will use the file present in the repository if present otherwise the one passed to the command.
Fixes #1323
Follow up off #1205