Fix --no-cache flag in git deployments#1020
Open
He-Is-HaZaRdOuS wants to merge 1 commit into
Open
Conversation
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed change
This PR fixes the "Disable build cache" option in git deployments not working due to the passing of the "--no-cache" flag to the wrong docker compose command.
Now the system detects and forces a fresh image build with the "--no-cache" flag, before attempting to deploy (up) the stack again.
Closes #880
Type of change
Additional notes & discussion
Changes were made and tested according to the insights of @jotka in issue #880, Thanks!. However, I do not believe that this PR alone would provide the behaviour that one would expect when they want to disable build cache (at least not for me...).
The main reason that I say this is that I expect that the new deployment will be made purely of the new image to be built from the incoming git changes from upstream. However, what actually happens is that the changes from git are being copied over to the current (or old, depending on how you see it) build context in a dirty fashion, and then docker is instructed to build the image from this new source code.
I believe this behaviour is to maximize caching of source artifacts that don't change often (if at all!), and also to preserve non-git tracked files or artifacts such as local media, local databases, whatever the deployed service may generate or store in a host mount volume.
This "dirtiness" of the build context causes build issues for me when using Microsoft's .NET framework whenever I delete, rename, or move a file, the old stale counterparts still exist from the previous deployment in the current build context and cause a namespace collision when building the project because the deleted and newly added files may both define the same namespace, and that isn't allowed in .NET or whatever.
My hacky solution for this is to track the current source code and the incoming source code files, and basically nuke away any current files that don't exist in the git repo anymore, as to avoid the aforementioned namespace collisions. Why not nuke all the source code? Again, local media files may be stored in host mounts on the host machine, and those may contain sensitive info that one may not intend to delete when disabling build cache so.... I ignore any files that neither exist in the current and incoming source code.
This change-tracking commit is not part of this PR however, it's on https://github.com/He-Is-HaZaRdOuS/dockhand/commits/main/ in case any reviewer is interested in this niche case that I encountered, I'd be happy to provide more information or discuss it more (although my fork and local image build of dockhand is serving me just fine for the time being).
Anywho... This PR is fine as-is from an objective standpoint, and thanks for the opportunity!