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 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 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>
Hidde Beydals
Stefan Prodan
Michael Bridgen