Allow specifying the path for manifests updates

[stefanprodan]

Changes:

• Add optional path field to spec.update, defaults to the git repo root
• Restrict updates to the specified spec.update.path

Fix: #100 fluxcd/flux2#1099

[stefanprodan]

TODOs after this gets merged and release:

• add --path to flux create image update
• explain how path can be used to restrict updates for each env in https://toolkit.fluxcd.io/guides/image-update/

[squaremo]

Test please! All the bits are there, you could put it alongside the commit message test case. (They will need a bit of refactoring at some point, but don't worry about it now)

[stefanprodan]

@squaremo I can't run the tests locally, any idea what's going on?

Running Suite: Controller Suite
===============================
Random Seed: 1615888184
Will run 19 of 19 specs

2021/03/16 11:49:49 request: GET 127.0.0.1:57077/config-yoh54.git/info/refs?service=git-receive-pack
panic: 
Your test failed.
Ginkgo panics to prevent subsequent assertions from running.
Normally Ginkgo rescues this panic so you shouldn't see it.

But, if you make an assertion in a goroutine, Ginkgo can't capture the panic.
To circumvent this, you should call

        defer GinkgoRecover()

at the top of the goroutine that caused this panic.


goroutine 983 [running]:
github.com/onsi/ginkgo.Fail(0xc000c8c000, 0x13e, 0xc000a079d0, 0x1, 0x1)
        /Users/stefanprodan/go/pkg/mod/github.com/onsi/[email protected]/ginkgo_dsl.go:260 +0xc8
github.com/onsi/gomega/internal/assertion.(*Assertion).match(0xc000e45f90, 0x5aae958, 0x67ba5d0, 0x0, 0x0, 0x0, 0x0, 0x5912970)
        /Users/stefanprodan/go/pkg/mod/github.com/onsi/[email protected]/internal/assertion/assertion.go:79 +0x216
github.com/onsi/gomega/internal/assertion.(*Assertion).ToNot(0xc000563f90, 0x5aae958, 0x67ba5d0, 0x0, 0x0, 0x0, 0xc0006a06c0)
        /Users/stefanprodan/go/pkg/mod/github.com/onsi/[email protected]/internal/assertion/assertion.go:43 +0xc7
github.com/fluxcd/image-automation-controller/controllers.glob..func1.1(0xc000a01ad0)
        /Users/stefanprodan/go/src/github.com/fluxcd/image-automation-controller/controllers/suite_test.go:94 +0xf9
created by github.com/fluxcd/image-automation-controller/controllers.glob..func1
        /Users/stefanprodan/go/src/github.com/fluxcd/image-automation-controller/controllers/suite_test.go:92 +0x9d6
FAIL    github.com/fluxcd/image-automation-controller/controllers       4.934s
ok      github.com/fluxcd/image-automation-controller/pkg/test  0.263s  coverage: 71.2% of statements
ok      github.com/fluxcd/image-automation-controller/pkg/update        0.189s  coverage: 85.9% of statements
FAIL
make: *** [test] Error 1

[squaremo]

All looks good, thanks Stefan 🥭

[nomeelnoj]

I know it's a bit late, but would it be possible to add globbing to the path object? This would help handle the use case where resources are put into folders as follows:

apps/myapp/base/kustomization.yaml
apps/myapp/overlays/dev/deployment.yaml # image policy marker found here
apps/myapp/overlays/stg/deployment.yaml # image policy marker found here

Then, setting:

path: ./apps/**/dev

in the ImageUpdateAutomation would allow this folder structure to be supported, while allowing an ImagePolicy object with the same name (different objects in each cluster, with different policies, but each named myapp, e.g.) to be shared across all the workloads.

[therapy-lf]

I know it's a bit late, but would it be possible to add globbing to the path object? This would help handle the use case where resources are put into folders as follows:

apps/myapp/base/kustomization.yaml
apps/myapp/overlays/dev/deployment.yaml # image policy marker found here
apps/myapp/overlays/stg/deployment.yaml # image policy marker found here

Then, setting:

path: ./apps/**/dev

in the ImageUpdateAutomation would allow this folder structure to be supported, while allowing an ImagePolicy object with the same name (different objects in each cluster, with different policies, but each named myapp, e.g.) to be shared across all the workloads.

This will be very useful. Would be great if you implement this feature.