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>
- make the healthz endpoint a flag and give the value to the
controller runtime
- set up probe endpoints; copy the func from elsewhere for now
- add the probe defs to the deployment
Signed-off-by: Michael Bridgen <michael@weave.works>
This is the GitOps Toolkit convention. This commit also puts the
flags in the base deployment config, in the same order as for other
GOTK controllers.
Signed-off-by: Michael Bridgen <michael@weave.works>
The useful events to know about for the update automation are when it
either errors out while trying to update the git repo, or succeeds.
Signed-off-by: Michael Bridgen <michael@weave.works>
This gives the controller an event recorder, without using it yet, and
makes sure it is registered when setting everything up in main.go.
Signed-off-by: Michael Bridgen <michael@weave.works>
This is a convention among the GitOps toolkit controllers; if false,
the controller will watch only resources in the namespace in which
it's running.
Signed-off-by: Michael Bridgen <michael@weave.works>
Once the api/ directory has its own module, to which the top go.mod
refers, it needs to be copied over before running `go mod download`.
Signed-off-by: Michael Bridgen <michael@weave.works>
This includes changes to:
* Bump the Kubernetes dependencies to v1.19.3 to align
with the other toolkit controllers.
* Update controller-runtime dependency to v0.6.3 to align
with the other toolkit controllers.
* Update the source-controller dependency to the most recent
v0.2.2 version to include the v1beta1 API.
* Add the `pkg/gittestserver` dependency for the Git tests,
as this package was removed in a newer source-controller version.
* Bump the Go version to v1.15.
Signed-off-by: Hidde Beydals <hello@hidde.co>
I have factored out the controller name into an env entry. In a `run:`
field, it is possible (necessary?) to use shell syntax for referring
to the env entry.
If this works here, I'll backport it to image-reflector-controller.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
The initial implementation of image updates required a single image
policy, and updated every image field that used the image, in the git
repo. This mode has limited practical value, and rather than
elaborating on it, it would be better to concentrate on making the
more carefully thought-through "setters" mode.
It will be useful, for kustomizations e.g., to be able to set just the
tag or just the name (repository). This commit adds setters for those
to the schema -- they have the name of the image setter plus a suffix
of `:tag` or `:name`. For example:
newName: ubuntu # {"$imagepolicy": "ns:policy:name"}
newTag: 18.10 # {"$imagepolicy": "ns:policy:tag"}
It's difficult to test the files comparison if it contains all its own
assertions, since you can only test successes. This commit rewrites
the helper to use a func without assertions, that can be more roundly
tested.
This adds another means of updating files to the package pkg/update/,
in setters.go (and gives the existing file a better name).
In passing, I changed the test util for comparing before/after
updates, in pkg/files/, to give a little more context when comparing
file contents; and, since the comparison between actual and expected
is not symmetrical, I corrected the order of the args in the tests.
Previously: replace the YNode (yaml.Node) with a new one which is just
the replacement string.
Now: change the value of the YNode, and set it back in place.
This updates the image replacement to switch on the kind of the node,
and change the way the replacements are done for CronJobs.
CronJobs have PodTemplateSpecs embedded deeper in the structure.
This updates the package
github.com/squaremo/image-reflector-controller to a revision that also
uses controller-runtime 0.6.2 (and client-go etc., 0.18).
The ImagePolicy CRD has also changed, so I've also uodated the tests
involving that type.
Valeriano Manassero
Michael Bridgen
Hidde Beydals
Michael Bridgen
Stefan Prodan
Kevin McDermott