This repository was archived by the owner on May 3, 2022. It is now read-only.
Release controller exposes executor problems fixes #174 #178
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.
Release controller is a 2-step process: processing a release initiates a
new processing loop for the parental application. In the current
implementation the process never broughts strategy execution issues on
the surface, therefore a user has no way to troubleshoot their
application.
This change enforces controller to preserve failure condition in the
application object. In this case the condition will be
ApplicationConditionTypeReleaseSynced set to False with a reason
StrategyExecutionFailed.
The parental application was chosen to be the medium for this condition
(in contrast to choosing the relevant release object) because at this
stage the controller is handling the application object itself and
strategy executor is working on a duplet of releases. Under these
circumstances choosing the contender might be another alternative as
user is expected to check it first. On the other hand, contextually this
might be an irrelevant location: strategy problems are encorporated in
application spec template. Therefore application was identified as the
optimal condition holder.
Signed-off-by: Oleg Sidorov [email protected]