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
Is your feature request related to a problem? Please describe.
When a user attempts to update the credentials of Zarf-deployed service using zarf init and flags such as --artifact-*, --registry-*, or `--git- with values different from the existing ones, they receive a warning that these services cannot be updated during a re-init. Instead of ignoring these flags, we should require users to execute the command with flags that are not ignored.
Describe the solution you'd like
Given I have a cluster already initialized with a registry pull password of "original-value"
When I run zarf init --registry-pull-password="new-value"
Then Zarf errors out immediately and tells me to use zarf tools update-creds
Describe alternatives you've considered
One alternative to consider would be actually allowing the credentials to be changed on re-init. IMO better to keep things simple for now and keep these commands separate, even if we implemented this issue, we could always change to allowing in the future if users ask for it.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When a user attempts to update the credentials of Zarf-deployed service using
zarf init
and flags such as--artifact-*
,--registry-*
, or `--git- with values different from the existing ones, they receive a warning that these services cannot be updated during a re-init. Instead of ignoring these flags, we should require users to execute the command with flags that are not ignored.Describe the solution you'd like
zarf tools update-creds
Describe alternatives you've considered
One alternative to consider would be actually allowing the credentials to be changed on re-init. IMO better to keep things simple for now and keep these commands separate, even if we implemented this issue, we could always change to allowing in the future if users ask for it.
The text was updated successfully, but these errors were encountered: