You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If chartpress is run with unstaged changes that makes us require a image rebuild, what should we do?
Currently, the process chartpress works like...
Get the last commit where dependent files for an image where changed.
See if that image is available locally or at DockerHub and build it if it isn't.
So, if we have unstaged changes, chartpress will not rebuild or update the helm chart and images. I think it could be good to do this by default, but that the user may want to understand if this happens by being warned they need to commit those changes for chartpress to care.
I propose we add a check for unstaged changes of relevance and print a warning message about this. Oh no wait... chartpress could mess up badly unless we fail sometimes... Consider if it realize it requires a rebuild, but there are more unstaged changes of relevance for the image build. Then it could end up building a image for a commit tag that isn't representing the state of that commit.
We have to decide how we want chartpress to behave in at least two situations.
There are unstaged changes influencing an image, and...
the tag is not available and needs to be rebuilt
the tag is already available and doesn't need to be rebuilt
I think we should fail hard for 1), and for 2) the user at least needs to be informed.
Technically, to conclude if there are unstaged changes, we could use the currently unused (since 55fe935) function path_touched where we would pass the commit range of HEAD for it to catch staged and unstaged changes that has not yet been committed.
The text was updated successfully, but these errors were encountered:
I think checking for uncommitted changes is great. I would try to avoid doing things too strict or complicated, and just append ".dirty" to versions if there are uncommitted changes in the inputs, probably also omitting a warning. I don't think failing hard is what we should do.
If chartpress is run with unstaged changes that makes us require a image rebuild, what should we do?
Currently, the process chartpress works like...
So, if we have unstaged changes, chartpress will not rebuild or update the helm chart and images. I think it could be good to do this by default, but that the user may want to understand if this happens by being warned they need to commit those changes for chartpress to care.
I propose we add a check for unstaged changes of relevance and print a warning message about this. Oh no wait... chartpress could mess up badly unless we fail sometimes... Consider if it realize it requires a rebuild, but there are more unstaged changes of relevance for the image build. Then it could end up building a image for a commit tag that isn't representing the state of that commit.
We have to decide how we want chartpress to behave in at least two situations.
There are unstaged changes influencing an image, and...
I think we should fail hard for 1), and for 2) the user at least needs to be informed.
Technically, to conclude if there are unstaged changes, we could use the currently unused (since 55fe935) function
path_touched
where we would pass the commit range ofHEAD
for it to catch staged and unstaged changes that has not yet been committed.The text was updated successfully, but these errors were encountered: