This changes the API so that the checkout field has a ref, the same as
GItRepository. This means you can check out a branch or a tag or a
particular commit. Most of these won't work unless you supply a branch
to push to as well.
An addtional change is that you can leave out the checkout altogether,
and the ref will default to that given in the GitRepository, or its
default. In the latter case, again you will need to provide a push
branch.
Signed-off-by: Michael Bridgen <michael@weave.works>
This is a bit neater to read and write, and since I'm making breaking
changes anyway.
The name is now optional; an email is enough.
Signed-off-by: Michael Bridgen <michael@weave.works>
This finishes the v1alpha2 API, and rewrites everything needed so that
the controller supports it and the tests pass. For the most part, that
is just changing the location of fields. However, there's a few
notable extras:
- check that the `sourceRef` is a git repo (that's the default), and
that a `.spec.git` is supplied;
- change a test that blindly patched an update object, so that it
first gets the object it's patching. Previously, it succeeded
because it was OK to patch everything to empty strings, but that's
no longer the case since SourceReference.Kind is an enum.
Signed-off-by: Michael Bridgen <michael@weave.works>
This adds a v1alpha2 API, without changing the controller or tests to
use it (yet). The new API has roughly the desired shape, per
https://github.com/fluxcd/flux2/discussions/1124, but supporting only
things that the controller supports now.
It's necessary to give the v1alpha1 type a `storageversion` marker so
that 1. code generation keeps working, and 2. tests still work, since
they still expect v1alphav1 types. v1alpha1 will be removed once the
controller and tests are ported to v1alpha2.
Signed-off-by: Michael Bridgen <michael@weave.works>
- Add optional `path` field to `spec.update`, defaults to the git repo root
- Restrict updates to the specified `spec.update.path`
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
The `.spec.update` field has a default, which means you can leave it
out of new objects, and it will still be a valid spec. However,
existing objects will not be valid, because they will have a value for
`.spec.update` (so it won't get the default) which doesn't have a
value for `.strategy` (which is required, and an enum).
So: default the strategy field as well, so that existing objects are
still valid. This doesn't change the meaning of any existing objects,
since the outcome is the default, which is the only possible value
anyway.
Signed-off-by: Michael Bridgen <michael@weave.works>
It's convenient to be able to leave out the update strategy, since
there is only one possible value at present; and if there were
alternatives, the present choice would still be a reasonable
default. However, with the format as it is, this doesn't work with
OpenAPIv3 schema, so you have to supply a value, even though there are
no parameters:
```yaml
spec:
update:
setters: {}
```
A more self-explanatory format which _does_ work with defaulting is to
name the strategy rather than relying on the presence of a field:
```yaml
spec:
update:
strategy: Setters
```
The whole `update` field can be elided and left to default. This
doesn't preclude having other strategies later, even those with
parameters, e.g.,
```yaml
spec:
update:
strategy: Foo
fooParam: 5
```
This commit changes the API types and code that uses them, and the CRD
manifest, and adds a test that checks the defaulting actually works.
Signed-off-by: Michael Bridgen <michael@weave.works>
This commit upgrades the `controller-runtime` dependency to `v0.7.0`,
including all changes required to make all wiring work again.
- Upgrade `runtime` to v0.6.2 to include `controller-runtime` changes.
- Logger has been removed from the reconciler, and is now retrieved
from the `context.Context` passed to the `Reconcile` method and
downwards functions.
- Logger configuration flags are now bound to the flag set using
`BindFlags` from `runtime/logger`, ensuring the same contract across
GitOps Toolkit controllers, and the `--log-json` flag has been
deprecated in favour of the `--log-encoding=json` default.
- The `ChangePredicate` from `runtime` has changed to a
`ReconcileRequestedPredicate`, and is now chained with the
`GenerationChangedPredicate` from `controller-runtime` using
`predicate.Or`.
- Signatures that made use of `runtime.Object` have changed to
`client.Object`, removing the requirement to e.g. call
`runtime.Object#Object`.
- The `leader-election-role` was changed, as leader election now works
via the `coordination/v1` API.
Other notable changes:
- Upgrade of `image-reflector-controller` API package to include
controller-runtime changes.
- Upgrade of `source-controller` API package to v0.6.1.
Signed-off-by: Hidde Beydals <hello@hidde.co>
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>
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>
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>
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>
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>
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.
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.
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.
Hidde Beydals
Stefan Prodan
Michael Bridgen
LWJ
Michael Bridgen