-
Notifications
You must be signed in to change notification settings - Fork 13
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
Read dockerignore in dev and deploy commands #757
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff! Maybe we can reduce complexity a bit. I'd like to keep ReadDockerignore & TrimBuildFilesFromExcludes but other funcs we use from Docker's pks can be replaced with simpler ones. (I briefly reviewed the implementation of that extra funcs you put, they seem to do some OS specific stuff, resolve symlinks etc. and this is too much. I think we don't need them for now.)
We can just use this code here too, by moving it under x pkg. And also add this TrimBuildFilesFromExcludes to that func.
But what is the resaon behind it? Why do you want just subset of this funcionalities? If we want to reduce complexity then we already did. We have used functions that are already writter and working. If we want to copy them, then we need to write, test, think what part cut off etc... For example why do you want to not handle symlink (or any other funcinality)? I think we must be as most compatible with And about dockerignoreFiles I wrote it before I knew it that there is already such function. What we should do is replace it with the one from |
// And canonicalize dockerfile name to a platform-independent one | ||
relDockerfile = archive.CanonicalTarNameForPath(relDockerfile) | ||
excludes = build.TrimBuildFilesFromExcludes(excludes, relDockerfile, false) | ||
|
||
archive, err := archive.TarWithOptions(path, &archive.TarOptions{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about xarchive
package?
Should we refacto most of the content of deployServiceSendServiceContext
or simply delete xarchive
package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some other packages like service (or container) can use it, but it needs refactoring first. And here is small PR to add this to dev/deploy command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why putting too much logic on the cli. A lot of these validations are great but would make more sense on the core itself.
I would go with something simple and maybe move the validation on the backend
excludes, err := build.ReadDockerignore(path)
archive, err := xarchive.GzippedTar(path, excludes)
I agree on at least try to refactor this function. But I also agree to merge this one now if @krhubert works directly on the refactor version. |
Those functions won't work on server side and all must be used on cli where the service directory exists.
|
I don't understand why they will not work on the server side, we are getting the tar and extracting the content so we will have the same informations that the cli has. But anyway, same this can be done in another PR, this one can be merged |
@antho1404 can you approve in this case |
close #736