-
-
Notifications
You must be signed in to change notification settings - Fork 271
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
Fix interactive apply asks in no change situation #945
base: main
Are you sure you want to change the base?
Conversation
311c46b
to
326113f
Compare
@tarrow if when |
@yxxhero An excellent question; I'm not certain but my belief is "no". I do not use the preapply hooks but my understanding from https://helmfile.readthedocs.io/en/latest/#hooks is that they are intended to be used for two types of different things:
In the case of 1 there is an argument that user's may expect to have the opportunity to confirm this action. However it seems never to have been the case that the hooks that would be executed are displayed to the user. In this case the user has no idea what they are agreeing to (unlike creating, updating or deleting releases which are printed before hand). If this feature is desired I would probably recommend adding an additional flag ( In case 2 it seems pretty clear that they would want this contextual information printed before being given the decision to make; in this case I believe this patch is an improvement for the user experience |
@mumoshu WDYT? |
Please let me know if you require anything more from me; if you determine that some other behaviour is desired let me know and I may be able to update the PR in order to facilitate that |
@mumoshu ping |
@@ -1418,20 +1418,31 @@ Do you really want to apply? | |||
// Traverse DAG of all the releases so that we don't suffer from false-positive missing dependencies | |||
st.Releases = selectedAndNeededReleases | |||
|
|||
if !interactive || interactive && r.askForConfirmation(confMsg) { |
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.
@tarrow Hey! Thanks for your contribution. I was trying to understand the original issue and your change fully but had no luck so far unfortunately.. .so it would be great if you could clarify a bit!
In short, can't we just inject something like the below here?
if len(releasesToBeUpdated) == 0 && len(releasesToBeDeleted) == 0 {
return true, false, nil
}
(basically L1498-1501)
That way, I think we can fix the original issue without changing the behavior of preapply hooks.
I might have missed something but my mind says preapply hooks should run immediately before applying. Running it before prompting breaks that rule so I'm slightly inclined to not change it's behaviour this way.
BTW, do you have any motivation that you want some hooks to run even before prompting? We could add a new hook point for that, perhaps something like preprompt
.
Alterntively, you could just use the existing prepare
hook if you want some hooks to be run regardless of if there is any change to be applied.
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.
Hi @mumoshu! Thanks for the reply; sorry for the slow response.
In short, can't we just inject something like the below here?
Yes! I think we can; I'd be very happy with this solution if you are. I have uploaded an updated patch with this change.
For clarity: I don't use any of the pre-apply hooks. I was actually trying to minimise behaviour change.
I noticed in #522 you said that
preapply
is supposed to get triggered even on unmodified releases
I was trying to keep this behaviour. With this new patchset I believe that this will no longer be true. preapply
will now not be triggered if there are no unmodified releases. I added this to the commit message any updated the docs. Please do double check that you're happy with this since I don't understand if this change is desired (since I don't use preapply hooks).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
44541d2
to
9bbad20
Compare
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@mumoshu could you take a look at the review once more? 🙏 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
ping |
Thanks for the pings to keep this alive. To make it clear the Please do let me know what you think about it; happy to make adjustments or just continue the discussion about what is the most desirable behaviour. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
ping @mumoshu |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
ping @mumoshu |
@tarrow please fix ci issue. |
9bbad20
to
d886a49
Compare
@yxxhero Hi! As I mentioned in #945 (comment) I left these failing deliberately to illustrate the changes this PR would make and to confirm that @mumoshu was happy with them
Did the helmfile team decide that you're happy to change this behaviour? If so let me know and I'll update the snapshot :) |
d886a49
to
d802031
Compare
This commit makes the apply logic exit early in the event there are no changes to releases. I believe this effectively reverts helmfile#522. Fixes: helmfile#679 Signed-off-by: Thomas Arrow <[email protected]>
d802031
to
ed9f73a
Compare
@mumoshu WDYT? |
This commit moves the pre-apply hooks that are now always run since #522 outside of the check for interactivity or asking for confirmation.
It also moves
This does subtly change the behaviour of preapply hooks when apply is invoked in interactive mode. The hooks will always be run before confirmation is asked for. In the event there are no releases to delete or update the preapply hooks will still run. Given that each preapply hook command must be idempotent I don't believe this is an issue.
Fixes: #679