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>
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.
This moves the specificiation for the checkout of the git repo to a
struct `GitCheckoutSpec`; and, renames the field that's a reference to
a GitRepository so it has the suffix `Ref` per gitops-toolkit
convention.
A resource will be queued whenever it changes, so if you change each
resource every time you see it, you will spin through all of them
continually.
To avoid that situation, this commit changes the reconcile logic so
that the resource status is updated only
- if it actually make a commit; or,
- if `interval` has passed since it last updated the status
In a steady state, this means it'll run twice (once for whatever
triggered it, and once because it updated itself) then be requeued
`interval` later.
When I set my default branch for `git init` in ~/.gitconfig, tests
start failing. This is because go-git assumes a default of `master`
when e.g., pulling commits, but exec'ing git (as the test server does,
via gitkit) will get you a different branch.
The answer is to be explicit about the branch created in tests, and in
all operations like cloning. The natural end point is that the
automation object specifies a branch to use (or an empty value,
meaning let it default).
The runInterval spec field gives a period for scheduled automation
runs, so it'll get done regularly whether or not the dependencies
appear to have changed.
The lastAutomationRunTime status field records the last time the
particular automation completed a run, whether or not it made
changes. This is informational, and will help with scheduling periodic
automations.
An ImageUpdateAutomation refers to a git repository and may refer to
an image policy. Watch both of these kinds, and react to either
changing by queueing any automations that refer to them.
This adds a test for the controller, checking that it will commit and
push a change, with the given commit message. I think checking it made
the right change will need a bit of rejigging tests elsewhere, so I
can compare directory contents (as with pkg/update tests).
This makes the controller commit changes and push to the origin, when
it's run the update. There's some new fields in the
ImageUpdateAutomation type for specifying the commit message and
author.
Just to get points on the board, this gives ImageUpdateAutomation an
`update` field into which you can plug the name of an ImagePolicy
resource (from the image reflector controller). The idea is that the
automation will then replace the image in the policy, anywhere it's
used, with its latest version.
This is enough to clone the repo that's referenced in the
ImageUpdateAutomation resource. It reproduces a bunch of code from the
source-controller which is internal there, to avoid writing it from
scratch.
Hidde Beydals
Michael Bridgen