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.
The default branch is now `main`, so trigger builds from that branch.
Also: use a specific version of the action from fluxcd/pkg, to avoid
just getting the latest commit, whatever that is.
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.
kustomize build ./config/default hiccoughs on the patches (due to a
mismatch of namespace), while `kubectl apply -k` doesn't. I think this
change will make both work.
This factors out the function that checks directories for equivalence,
and uses it to check that the upstream repo has the expected update
when the controller has pushed its commit.
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.
Michael Bridgen
Hidde Beydals