This commit add the oci artifact digest into the release observed
snapshot. This is used to later to add that value as an annotation.
Signed-off-by: Soule BA <bah.soule@gmail.com>
When a Helm install or upgrade is performed, to prevent confusion due to
reporting a stale test result.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
From `<namespace>/<name>.<version>` to `<namespace>/<name>.v<version>`,
to better resemble the internal name format of e.g. Helm storage
Secrets.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures the logs of the Kubernetes client used by Helm are
persisted to the log buffer, as they can contain important information
when an action times out.
In addition, move the logs from the Helm actions themselves to the
"debug" log level (while still including them in Kubernetes Events in
case of a failure), in favor of the logs produced by the `reconcile`
package itself. While moving the logs from the Helm storage to the
"trace" log level, as they only contain information about e.g. writes
to a Secret.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This in an attempt to maintain compatability with earlier documented
inclusion and exclusion lists for Alerts, like the following:
```
eventSources:
- kind: HelmRelease
name: demo
inclusionList:
- ".*.upgrade.*succeeded.*"
```
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
The primary reason for this is the alphabetical ordering of `kubectl
describe`, which caused the fields to be listed in separate places
instead of a bundle.
From a programmatic perspective, it is also great because it is now much
easier to reset any previous state when e.g. uninstalling a release. As
we can simply write an empty struct to erase any memory of a previous
release, instead of having to deal with multiple fields.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This includes the "token" in the emitted events which is used to rate
limit events received by the notification-controller.
Either by using the already calculated config (values) digest, or by
calculating it for the current reconciliation request in scenarios
where it isn't available from made observations.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This commit adds an atomic release reconciler, capable of stepping
through a series of Helm actions. In addition, it adds the last bits
around eventing and summarizing the end state of the Condition types
into e.g. a Ready condition.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This provides a rough (but not flawless) outline for determining the
sub-reconciler which should run based on the state of the `HelmRelease`
API object, and the Helm storage.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a `reconcile` package with the reconciliation and (status)
observation logic for individual Helm actions, but no glue to loop
through them till desired state.
All actions have individual `ActionReconciler` implementations which
construct their `action.Configuration` out of a factory, so the Helm
client can be shared between sub-reconcilers. They all present a
`ReconcilerType`, allowing an iterator to e.g. stop after running
every type just once.
The observation model can be explained as follows, but may lack some
minor details:
- The observed release has to match the release target of the
HelmRelease object
- ActionReconcilers of type "release" move Current to Previous
when they see a higher release revision. They then write the
new release to Current, and continue to observe writes to
revisions that match either version
- Remediation only updates Current
- Test updates Current and Current.TestHooks
- Unlock updates Current
After running the action, the reconcilers observe both the action
result and the state of the object. This allows them to distinguish
certain types of errors which are otherwise hard to detect.
For example, errors which do not cause drift to the Helm storage, or a
change of release version compared to Current for actions which do not
provide a version target flag.
Signed-off-by: Hidde Beydals <hello@hidde.co>