Add action to update chart and CRDs #18
Conversation
|
Here are instructions to manually test the helper programs Chart version update # Currently checked out chart release is 0.2.0.
# Restore chart files to the previous release.
$ git checkout contour-0.1.0 charts/contour/Chart.yaml charts/contour/values.yaml
$ git restore --staged charts/contour/Chart.yaml charts/contour/values.yaml
# Do the version bump.
$ go run hack/actions/bump-chart-versions/main.go
INFO[0000] Current chart version: 0.1.0, appVersion: 1.32.0
INFO[0000] Latest stable Contour: 1.33.0, Envoy: 1.35.2
INFO[0000] Updated Contour chart version to 0.2.0 in ./charts/contour/Chart.yaml
INFO[0000] Updated Contour chart appVersion to 1.33.0 in ./charts/contour/Chart.yaml
INFO[0000] Updated Contour image tag to v1.33.0 in ./charts/contour/values.yaml
INFO[0000] Updated Envoy image tag to v1.35.2 in ./charts/contour/values.yaml
INFO[0000] Successfully bumped versions.
# Compare programmatic bump with the manual 0.2.0 release.
$ git diffDiff output is attached here: bump-chart-versions.diff.txt Notes: There are minor formatting differences in the YAML, but the programmatic bump follows valid and consistent YAML formatting conventions. CRD update # Currently checked out chart release is 0.2.0.
# Restore CRD files to the previous release.
$ git checkout contour-0.1.0 charts/contour/templates/crds/contour-crds.yaml charts/contour/templates/crds/gateway-api-crds.yaml
$ git restore --staged charts/contour/templates/crds/contour-crds.yaml charts/contour/templates/crds/gateway-api-crds.yaml
# Do the CRD sync.
$ go run hack/actions/synchronize-crds/main.go
INFO[0000] Current chart appVersion: 1.33.0
INFO[0000] Downloading Contour source tarball for version 1.33.0 to /tmp/contour-source-3944172338/contour.tar.gz
INFO[0001] Wrote Contour CRDs to ./charts/contour/templates/crds/contour-crds.yaml
INFO[0001] Wrote Gateway API CRDs to ./charts/contour/templates/crds/gateway-api-crds.yaml
INFO[0001] Successfully synchronized CRDs.
# Compare programmatic CRD update with the manual 0.2.0 release.
$ git diffDiff output is attached here: synchronize-crds.diff.txt Notes: The automatic update does not include the original CRD file Github URL or Contour version in the comments within the CRD template files. I believe this is unnecessary, since the update process ensures that the files are from the correct place and aligned with the chart’s appVersion. Github workflow The workflow logs from the initial run of the "update contour helm chart and create pull request" step look similar to the following: The PR that is created looks like this 
The commit message is the same as PR title and the commit has:
Workflow logs when the script runs again while a PR branch already exists When there are no updates ( This does consume some bandwidth before the script detects that it should not proceed. |
tsaarni
force-pushed
the
chart-version-bump-action
branch
3 times, most recently
from
d62e046 to
bb76637
Compare
tsaarni
force-pushed
the
chart-version-bump-action
branch
from
bb76637 to
be430a0
Compare
Signed-off-by: Tero Saarni <[email protected]>
tsaarni
force-pushed
the
chart-version-bump-action
branch
from
be430a0 to
27a7009
Compare
|
|
||
| on: | ||
| schedule: | ||
| - cron: '0 4 * * *' # Runs daily at 04:00 UTC |
There was a problem hiding this comment.
The optimal trigger would be from https://github.com/projectcontour/contour/ when a release is created
There was a problem hiding this comment.
I believe action cannot be triggered by event in main repo, and the default GitHub token granted for actions don’t allow cross-repository permissions i.e. release action in main repo cannot do something in helm chart repo through github REST API by using the github token that it receives.
One option mentioned in the docs is for maintainer to create a PAT with the needed scopes and storing it as a repository secret, but I’d prefer not to tie personal tokens to automation.
Another option is using a GitHub App registered at the organization level, which could be granted broader permissions. Normally Github Apps would run as a web service outside GitHub which sounds too much of a burden to maintain, but the create-github-app-token action might bridge the gap by generating app tokens directly within a workflow, although I’m not fully sure if I understood it correctly.
Cron based trigger and polling is trivial approach and works around the permission problem :)
| // Compare if versions are the same. | ||
| if contourVersion == currentChartAppVersion { | ||
| log.Infof("Contour version %s is already up to date", contourVersion) | ||
| return |
There was a problem hiding this comment.
Do you need to stop this early?
I'm thinking that the rest of the checks are cheap enough to always run, and that you'd get a more robust solution by going through the entire flow and cancelling if the files haven't changed
Although the only case I can think of is that we might get a version update where the YAML is serialized slightly different to before, and even that seems relatively unlikely 🤷♀️
There was a problem hiding this comment.
Although in that case, the title/description of the PR really should be different - and if this is triggered from a release being created upstream then all that's moot really
2 participants
This PR introduces two helper programs intended to be used in GitHub Actions:
The workflow is triggered either nightly or manually. We may want to consider whether this is the optimal trigger strategy.
Fixes #15