Support for more complex message from manifest commit message to dispatch event. (To handle flux image automation where list images is set by default). Fix errors with deploys being marked failed prematurely. #39
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.
A few updates to handle using this with flux image automation, and also to resolve an issue where successful commits get marked as failed prematurely.
Add try/except around extracting the runId and commitId from the source commit message, also passing along the unparsed commit message to support cases like flux image automation where there may be multiple image updates from commits/runs batched into a single manifest commit, and where it may be difficult to add a commit message formatted for extracting a runId/commitId.
Changed DependencyNotReady mapping from error to pending. Once a commit status with error status is sent to github the commit itself goes into the failure status, and from there gitops-connector stop processing further messages for that commit. DependencyNotReady can be emitted during a deployment that is ultimately successful. I also think HealthCheckFailed may have the same issues, a health check may fail as a container is initializing and then ultimately end up succeeding so we wouldn't want a single failure to cause a failed commit I don't think?
This discussion from flux maintainer suggests that DependencyNotReady just means reconciliation is in progress and not an indication of failure.
fluxcd/flux2#1160
Also I am unsure how to test this in my own cluster ahead of time, so just wanted to call out that these changes haven't been tested live but I believe they are simple enough.