The image name was incorrectly extracted from the given reference,
yielding a trimmed version of the string and breaking the resulting
replacement value.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>
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>
This explains the data available to the commit message template in the
API guide. While writing it, I realised it could be made more
convenient, so:
- mask external types by embedding them
- make the most useful parts of an image ref available using a
wrapper struct and interface
Signed-off-by: Michael Bridgen <michael@weave.works>
It's desirable (see #6) to be able to enumerate the updates that were
made by automation, in the commit message and perhaps in an event
announcing success.
Doing this is counter-intuitively difficult. A `kyaml.setters2.Set`
filter will keep a count of the times its used. Previously, one `Set`
was used with the `SetAll` flag set, which would replace any marker
that corresponded to an image, in one traversal. But to keep track of
images individually, you need to have a setter for _each_ image (and
its tag, and its name, since those can be used separately). This means
`3 x policies` traversals of each node! The saving grace, possibly, is
that only files with a marker in them are considered.
Since you might want to dice the results in different ways, the result
returned is a nested map of file->object->image.
Signed-off-by: Michael Bridgen <michael@weave.works>
In general a copyright notice takes the form:
Copyright year name
.. where the year is the year of first publication, to let people know
from when the copyright applies. It's fairly common in software to
affix additional years in which the software was modified and
released. I have chosen here to use `2020, 2021` for the new and
modified files; it is OK that not _all_ files are updated, since the
important bit is the _first_ year, which they already have.
Signed-off-by: Michael Bridgen <michael@weave.works>
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 adds another means of updating files to the package pkg/update/,
in setters.go (and gives the existing file a better name).
In passing, I changed the test util for comparing before/after
updates, in pkg/files/, to give a little more context when comparing
file contents; and, since the comparison between actual and expected
is not symmetrical, I corrected the order of the args in the tests.
Previously: replace the YNode (yaml.Node) with a new one which is just
the replacement string.
Now: change the value of the YNode, and set it back in place.
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.
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.
Aurel Canciu
Stefan Prodan
Michael Bridgen
Michael Bridgen