This pullrequest proposes a few improvements to the Updatecli pipelines used on this repository.
Add a policy to update containers defined in app.yaml
This policy updates container image tags defined in files app.yaml.
Containers to monitor must be specified in the values file .github/updatecli/values.d/apps.yaml
The policy generates one update pipeline per app where an app can contain multiple containers.
To show generated pipelines you can run:
updatecli manifest show --config .github/updatecli/updatecli.d/apps/containers.tpl --values .github/updatecli/values.d/scm.yaml --values .github/updatecli/values.d/apps.yaml
Please note that the current policy don't handle all images defined in app.yaml.
Running grep "image: " $(find . -name "app.yaml") shows me 52 images to monitor for 38 apps and I only listed 12 app to monitor in .github/updatecli/values.d/apps.yaml
Monitoring all images would would open 38 pullrequests and each of them would need to be tested
In future, It should be pretty straightforward to add more to the file .github/updatecli/values.d/apps.yaml
Cleanup existing Updatecli pipeline
Update yaml query used within yaml plugin to be "yamlpath" compliant.
For example version becomes $.version
Update target name to be semantic versioning compliant
For example Bump Jenkins Helm chart to {{ source "version" }} becomes deps: bump Jenkins Helm chart to {{ source "version" }}
Update Updatecli GitHub action workflow to use updatecli "compose" file
I find it easier for rganizing the Updatecli pipelines are executed by relying on the file update-compose.yaml instead of modifying the GitHub action workflow
This pullrequest proposes a few improvements to the Updatecli pipelines used on this repository.
Add a policy to update containers defined in app.yaml
This policy updates container image tags defined in files
app.yaml. Containers to monitor must be specified in the values file.github/updatecli/values.d/apps.yamlThe policy generates one update pipeline per app where an app can contain multiple containers. To show generated pipelines you can run:
To test what this policy would change:
I tested this policy on olblak/kubernetes-marketplace where you can see the kind of pipeline that would be opened.
Please note that the current policy don't handle all images defined in app.yaml. Running
grep "image: " $(find . -name "app.yaml")shows me 52 images to monitor for 38 apps and I only listed 12 app to monitor in.github/updatecli/values.d/apps.yamlMonitoring all images would would open 38 pullrequests and each of them would need to be tested In future, It should be pretty straightforward to add more to the file.github/updatecli/values.d/apps.yamlCleanup existing Updatecli pipeline
Update yaml query used within yaml plugin to be "yamlpath" compliant. For example
versionbecomes$.versionUpdate target name to be semantic versioning compliant For example
Bump Jenkins Helm chart to {{ source "version" }}becomesdeps: bump Jenkins Helm chart to {{ source "version" }}Update Updatecli GitHub action workflow to use updatecli "compose" file
I find it easier for rganizing the Updatecli pipelines are executed by relying on the file
update-compose.yamlinstead of modifying the GitHub action workflow