Skip to content

Latest commit

 

History

History
54 lines (44 loc) · 2.68 KB

CONTRIBUTING.md

File metadata and controls

54 lines (44 loc) · 2.68 KB
Raw

Releasing

Workflow:

  1. Tag all needed container image repos, kwctl.
  2. Wait for all their release jobs to finish and create their GH Release entries, with their release assets.
  3. Notice that the release jobs from kubewarden/kubewarden-controller and kubewarden/audit-scanner habve a last step, which is a workflow dispatch that triggers the update-charts.yml workflow in kubewarden/helm-charts.
  4. The update-charts.yml workflow in kubewarden/helm-charts succeeds, which opens a PR against this repo to review.
  5. The PR doesn't trigger CI (see here). Workaround: close the PR and immediately open it.
  6. Review the PR. Note that you should review the changes since the last available release of the charts up until the PR contents, but not only the PR contents. And easy way to do that is to do a compare between the last tag and the branch of the PR (see this example).
  7. Merge the PR. This triggers release-drafter
  8. Check that the charts are generally available.
  9. Check that https://github.com/kubewarden/helm-charts/releases is correct.
  10. Create new versioned docs as needed, by merging the automated PR against kubewarden/docs, and triggering Algolia's crawler.

Helm chart repo automation

Releases of the helm-charts are automated via the helm-chart-release workflow, using chart-releaser. Once a chart with a bumped version arrives in main, it will get consumed by chart-releaser, which takes care of building the chart and publishing it to the gh-pages branch.

Helm chart contents automation

The repo also has automation for the contents of the helm chart themselves.bumping the charts, by consuming container images and other assets such as CRDs, and making diffs with updatecli.

It may happen that several workflow dispatches get triggered against kubewarden/helm-charts repo. The dispatches may happen before GH has made the GH release assets public. For example, the dispatch from kubewarden/kubewarden-controller may trigger a new "Update charts" job in kubewarden/helm-charts, and, the GH Relase page for the controller may be showing the correct assets, but the helm-charts workflow may have not yet seen the changes (because of caching, etc).

This issue can happen for several dispatches, as one normally tags the container images in succession.

Workaround

The easy workaround is to wait some minutes for the dust to settle, and retrigger all the jobs. There will be one that is successful, and will open a PR against kubewarden/helm-charts for review.