feat: use server side apply for dry runs where possible #725
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.
Hi, excited to say this is my first PR to the argoproj. This PR proposes a solution to issue #631. I am very happy to write up this proposal more formally in a design doc, comment to an existing issue or a new one if preferred - please let me know if any preference.
Proposal
This PR proposes that Dry Run syncs leverage server side apply for rich validation and feedback in the spirit of shifting left. For us at least, this would be very useful to improve parity of feedback between pre merge and post merge CI builds - surfacing feedback from various validation webhooks and policies.
Notably server side apply dry runs and the auto-create namespace feature are not compatible - the server side dry run feedback would just fail that the namespace does not exist. Therefore this PR proposes that in this case we fall back to client side apply.
alternatives
I see 2 alternatives:
return an error to the user if a sync is performed where: server side apply is enabled, dry run is enabled, auto namespace creation is enabled. This approach would have the benefit of not being misleading (with the current proposal it is not obvious that a client side apply is being used as a fallback )
do nothing and stick with client side apply. I would like to advocate strongly against this route as server side apply has the potential to give much richer feedback to users. At least for us there is a lot of value in using server side apply for dry runs with the amount of validation policies and so forth we have.