This message was deleted.
# epinio
a
This message was deleted.
w
there currently isn't a way to pass a path or a glob to ignore, but you can pass a
-p
for a specific path (like in a mono-repo). We have an open feature issue for it though. https://github.com/epinio/epinio/issues/2589 - feel free to add any feedback there!
currently, these are the paths ignored by default (git related)
Copy code
var excludedGitFiles = []string{
	".git",
	".gitignore",
	".gitmodules",
	".gitconfig",
	".git-credentials",
}
l
Wouldn't a "quick" way be to ignore .gitignore paths? Most projects already use it to define paths that should be dev-only/irrelevant to the raw codebase of the project anyway. It could even be .epinioignore or something similar, if people need more fine-grained control for some reason. But for rails projects for example, epinio now pushes the entire cache directory, log directory and storage directory, which all might be very large during the development of a project. And while cache and log can be cleared before pushing with no real impact,
storage
might have assets that is not practical to delete or have to move out of the project and back in after a push.
w
I said the same thing a few years ago (we weren't involved in the project yet), and there were situations we found where we needed files which were git-ignored, like file-based-config situations where someone inserted a file with variables they wanted to protect from committing to the repo.
👍 1
so at that time we agreed that it was necessary to provide separate controls/options for that
👍 1
project.toml does have https://buildpacks.io/docs/for-app-developers/how-to/build-inputs/use-project-toml/ include and exclude examples when using
pack
. It makes it seem like it's a spec/standard but, from the CNB maintainers, it's up to the platform providers to choose what to implement there and isn't part of spec. It was just a design decision for
pack
but reworking that part of the pipelines is one of the "up next" items for us. We just have to do it in a way that doesn't break existing users. IMO adding the project.toml support will resolve this for us.
l
Yes it seems like it would. But that would still mean that epinio would push unnecessary (potentially also sensitive) files by default, even if pack eventually ignores them, right?
w
not if we eval the project.toml for certain options
l
oh, on the cli side, right.