feat(file): Allows to use file pattern in the file/files key

[olblak]

Fix #1453

This pullrequest allows to use common file path pattern with the plugin "file"

name: Test file resource without scm 

sources:
  adoptersWithFilePattern:
    name: "Get content from each file(s) matching pattern ADOPTE??.md"
    kind: file
    spec:
      file: ADOPTE??.md
      searchpattern: true

Test

To test this pull request, you can run the following commands:

cd pkg/plugins/utils/
go test
go build -o bin/updatecli . 
./bin/updatecli diff --config e2e/updatecli.d/success.d/file/noscm.yaml --debug

Additional Information

Tradeoff

Instead of reading a specific file, the change introduce in this pullrequest will try to locate ALL files matching pattern which obviously has performance consequence...
I could think of two options to mitigate this:

1. Using a flag to enable/disable this behavior such as

sources:
  adoptersWithFilePattern:
    name: "Get content from each file(s) matching pattern ADOPTE??.md"
    kind: file
    spec:
      file: ADOPTE??.md
      filepattern: true

But I find this approach a bit cumbersome

2. Using a different key such as

sources:
  adoptersWithFilePattern:
    name: "Get content from each file(s) matching pattern ADOPTE??.md"
    kind: file
    spec:
      filepattern: ADOPTE??.md

But this would imply more code to write and maintain as I'll need to handle the different combination of file,files,filepath, filespath

I don't think the performance impact is that critical but I am open for suggestion

edit
I decided to implement the flag approach using searchpattern instead of filepattern

Potential improvement

Implement similar pullrequest for

• xml
• json
• toml
• yaml
• csv

[olblak]

While the idea remain the same, the broken e2e highlight that the current implementation is wrong. It doesn't handle scm

[olblak]

I updated the e2e tests to cover the additional scenarios

[dduportal]

• First of all, the use case looks really legit and it is a good idea!
• Code is LGTM
• No regression with the binary I've tested from this PR (tried with jenkins-infra/jenkins.io updatecli manifests)
• The "opt in" behavior with addition field is really good
• Only missing element is: what "kind" of pattern. (Said differently: "as a user where can I find example of the pattern matching?)

=> Approving, but don't forget to add a documentation update even after merging/releasing the feature ;)