This adds fields to the ImageUpdateAutomation status for recording the
commit last pushed; handy to see when you are expecting a change.
It also adapts the "steady state" message of the ready condition to
mention the last commit, in case that's where people are looking.
Signed-off-by: Michael Bridgen <michael@weave.works>
After a change has been made, the ready condition should have a
message indicating that it pushed a commit.
Signed-off-by: Michael Bridgen <michael@weave.works>
Instead of having an arbitrary default branch, make the checkout
branch mandatory. This needed a little finessing in the tests, since
they did not cover using different branches (though did cover using a
non-standard branch).
Signed-off-by: Michael Bridgen <michael@weave.works>
In general a copyright notice takes the form:
Copyright year name
.. where the year is the year of first publication, to let people know
from when the copyright applies. It's fairly common in software to
affix additional years in which the software was modified and
released. I have chosen here to use `2020, 2021` for the new and
modified files; it is OK that not _all_ files are updated, since the
important bit is the _first_ year, which they already have.
Signed-off-by: Michael Bridgen <michael@weave.works>
This is intended to address two problems:
- LocalPackage{Reader,Writer} like to reformat the YAML that passes
through them; mostly this is harmless, but occasionally it will end
up fighting format tooling, e.g., prettier.
- It's possible that things like Helm chart templates are lying
around in the git repository to which automation is applied. Those
templates have extensions of ".yaml" but are not usually parseable
as YAML, so would result in errors from the file reader.
This commit changes how updates are run -- firstly, it screens files
by checking for a token (`"$imagepolicy"`) that will be present in
files that might need updating. This cheaply removes some nodes --
likely including Helm chart templates -- from consideration.
Secondly, it now only writes files that were actually updated by an
imagepolicy setter, rather than writing everything that was an
input. This means it's less likely to reformat something that doesn't
need to be touched at all.
Signed-off-by: Michael Bridgen <michael@weave.works>
This also corrects a defect in the Makefile: if it can't fetch the
CRDs successfully, it should fail. (Otherwise, it just write the 404
resopnse body to the expected-CRD file!)
Signed-off-by: Michael Bridgen <michael@weave.works>
The paths field in update.setters is to restrict the update to files
in particular paths.
But this is not implemented, and although it sounds useful, it's not
clear it's necessary. Until there's a known problem to be solved by
it, I'm removing it.
Signed-off-by: Michael Bridgen <michael@weave.works>
This changes the value of $IMG in the Makefile to line up with other
GitOps toolkit controllers. The main effect is the the `kustomize edit
image` commands used in the deploy and dev-deploy targets will now set
the image tag, rather than let it stay at whatever the last release
was.
Signed-off-by: Michael Bridgen <michael@weave.works>
This adds the external event recorder (a.k.a., notifications client)
to the reconciler, and expands the definition of
`<reconciler>.event(...)` so that it will send a notification whenever
an event is emitted. This is the conventional way of handling events
amongst the GitOps Toolkit controllers.
Signed-off-by: Michael Bridgen <michael@weave.works>
The convention is now to simply exit, when a GOTK object is
suspended. Previously this would update the status to indicate that it
was unready; now it just leaves it in whichever state it was before.
This also applies to the reconcile request annotation; it will _not_
be marked as seen if the object is suspended. The effect of this is
any change to the object will be passed by the predicate and therefore
reach Reconcile, until the object is unsuspended. Since it will _also_
exit early until unsuspended, this is harmless except for some extra
log lines. (But changing that ordering might be worth considering in
the future.)
This change required a few changes to tests:
- to check that suspend makes the reconciliation exit without doing
anything, explicitly run `r.Reconcile(...)`.
- to avoid waiting for the reconciler's caching client to see
changes, use an uncached client.
- (fix a problem caused by comparing a time pointer with its alias)
Signed-off-by: Michael Bridgen <michael@weave.works>
The convention among GOTK controllers is to use a "reconcile request"
annotation to force a reconcilation, outside of spec or dependency
changes. This is used by e.g., the incoming webhooks handler. The
predicate `ChangePredicate`, already used by this controller, takes
this into account by allowing events that either caused the generation
to increment, _or_ changed the reconcile request annotation.
This commit adds a test that the automation will indeed run when the
annotation is set. This is a little delicate, because I have to rule
out _other_ reasons it might run. To do so, the test makes a change to
the git repo that will be overwritten by an automation run -- a commit
will not trigger a Reconcile call since it's entirely outside
Kubernetes.
Signed-off-by: Michael Bridgen <michael@weave.works>
The GitOps toolkit controllers usually adopt the maintainers of the
"central" Flux v2 git repo, fluxcd/flux2. For convenience of keeping
track, it is easier to refer to the MAINTAINERS file there.
NB this expands the maintainers of this repo, but only to those who
were effectively considered maintainers anyway (i.e., it reflects the
established practice.)
Signed-off-by: Michael Bridgen <michael@weave.works>
The `LastAutomationRun` field records the last time the automation
completed, whether it made changes or not. The purpose is to inform
users, so they can check against their expectations.
It should only be set once the automation run has completed without
error, otherwise it will provide false reassurance that things are
happening when they are not.
Signed-off-by: Michael Bridgen <michael@weave.works>
This gives ImageUpdateAutomation objects .status.conditions and
.status.observedGeneration fields, which are maintained by the
controller in the GOTK-standard way.
The only condition used is a Ready condition, compatible with kstatus
(and in common with other GOTK controllers). An object is marked Ready
if the reconciliation exits without an error, whether or not changes
were actually made. If the automation run cannot proceed, e.g.,
because the git repository referred to does not exist, or is not
cloneable, it will be marked as not ready.
This means the condition is a reliable guide to whether the particular
automation is operating or not; new objects will be marked ready as
soon as they have been run through successfully, and will stay ready
until there's a problem. Generally, if there _is_ a problem, the
object will be requeued with a backoff, or left to wait until
circumstances change (e.g., the object itself is edited); one way or
another, there will be a retry, and thereby an opportunity to
transition to ready.
Signed-off-by: Michael Bridgen <michael@weave.works>
Broadly,
- remove prometheus, webhooks and certificate handling
- use standard names and filenames
- don't authenticate the metrics endpoint
Signed-off-by: Michael Bridgen <michael@weave.works>
Stefan Prodan
Michael Bridgen
Valeriano Manassero