This mostly adapts the material in the v1alpha1 spec explainer doc to
the different structure of the v1alpha2 types.
Signed-off-by: Michael Bridgen <michael@weave.works>
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>
The update procedure is obliged to return a Result struct with all the
objects that were changed, for filling in the commit template. At
present, the result is collated by running each setter on each object
and seeing if the setter is used. This uses the `Set` from kyaml, with
a small amount of glue.
It doesn't quite work, however, because a setter may be used for a
field without changing the value. The result gets an entry for each
policy _mentioned_, whether or not it had a new value. There is no way
to see whether a setter actually changed a field from the outside,
other than by comparing a copy of the object before using the setter
with the object after (which yaml.v3 does not make easy).
A better approach is to get the setter to record whether it changed
anything, since it is there doing the changing. This means
reimplementing kyaml's `Set`. I have stripped it down to the parts
needed for image updates -- so e.g., only field values are examined.
Signed-off-by: Michael Bridgen <michael@weave.works>
With reference to
https://github.com/fluxcd/image-automation-controller/issues/133
this commit adapts the update->result test so that it checks an
additional case: that a field with an update marker that _does_
correspond to a policy, but _doesn't_ get changed, is not included in
the results.
This test fails at present, because the method for determining the
result is to count which setters are referenced, rather than which
fields were changed.
Signed-off-by: Michael Bridgen <michael@weave.works>
There is a bug in go-git which leads to it reporting broken, absolute
symlinks as modified whether they are or not:
https://github.com/go-git/go-git/issues/253
To date, the controller checks whether the repo it has run an update
on is Clean, and as a consequence will run into the bug above if a
broken symlink is in the repo. The result is that it makes and pushes
an empty commit every interval.
To work around the problem, this commit adds a more careful check of
the repo status. Each file reported as modified is validated by
checking specifically that it's not a broken symlink: if `os.Lstat`
says it's a symlink and `os.Stat` reports the (target) file is
missing, it can be ignored. (Why not just ignore any missing file?
Because a missing file might indicate some other problem, so better to
let it fail).
For convenience, I have moved a few procedures around so they can be
used more readily by go tests.
Signed-off-by: Michael Bridgen <michael@weave.works>
For the "push to branch" feature, the controller must either switch to
the branch given, or create it starting at the checked-out HEAD. The
func `switchBranch` encapsulates this decision -- but it assumes that
if the branch exists at the remote, it will have been fetched when
cloning, and this is not always true. In particular, cloning with
go-git avoids fetching all refs:
https://github.com/fluxcd/source-controller/blob/v0.11.0/pkg/git/gogit/checkout.go
This commit adds a step to fetch the remote branch to a local branch,
before attempting to switch to the local branch. This makes
`switchBranch` a little simpler, and doesn't rely on any refs having
been fetched ahead of time.
Signed-off-by: Michael Bridgen <michael@weave.works>
Prior to #27, controller indexed the automation objects against image
policies, since an automation could depend on a specific image
policy. That PR removed the references and the watch; however,
automation objects still depend on image policy objects, just
indirectly through the git repo.
This commit reinstates the watch, and makes sure the generation change
/ reconcile request predicate applies only to the watch on automation
object themselves.
Signed-off-by: Michael Bridgen <michael@weave.works>
This adds a test to check that should there be a further update to
make, another commit is pushed to the "push branch". In this case, the
image policy gets a new latest image.
The test fails at present because the controller is not watching image
policies (and will not run again on the long interval specified).
Signed-off-by: Michael Bridgen <michael@weave.works>
This changes the functionality when updating the status to use Patch
rather than Updating, which is more resilient to changes.
Signed-off-by: Kevin McDermott <bigkevmcd@gmail.com>
Hidde Beydals