Github Workflow Configuration

Extension Charts Workflow

To build the charts needed to provide a Helm repository, use the reusable workflow job found here. When published you will be able to target the Github repository as a Helm repository, which will serve the charts for installation within the Rancher Dashboard.

Workflow Permissions

Each workflow requires permissions to be set correctly to complete the release processes, both builds have specific needs with some overlap:

Property	Extension Type	Permission	Description
actions	Charts/Catalog	write	Requires write to cancel a workflow.
contents	Charts*/Catalog	write*/read	Requires read for actions/checkout, and requires write (*only necessary in the Chart Build workflow) to put the contents of the built extension charts into a branch.
deployments	Charts	write	Requires write when deploying gh-pages.
packages	Catalog	write	Requires write when a catalog image is created to create the package.
pages	Charts	write	Requires write to request and create page builds for the deployment.

Extension Chart Inputs

Property	Required	Description
permissions	true	This gives the workflow permissions to checkout, build, and push to the repository.
target_branch	true	The Github branch target for the extension build assets
tagged_release	false	Specifies the tag name when triggering workflows by publishing tagged releases. (Requires alternate dispatch rules)

Example usage

...
jobs:
  build-extension-charts:
    name: Build and release Extension charts
    uses: rancher/dashboard/.github/workflows/build-extension-charts.yml@master
    permissions:
      actions: write
      contents: write
      deployments: write
      pages: write
    with:
      target_branch: gh-pages

Extension Catalog Image Workflow

To build an Extension Catalog Image (ECI) for air-gapped/private repositories, use the workflow found here. This will build and push the container image push into the specified registry.

Extension Catalog Image Inputs

Property	Required	Description
permissions	true	This gives the workflow permissions to checkout, build, and push to the registry.
registry_target	true	The container registry to publish the catalog image
registry_user	true	The username connected to the container registry
tagged_release	false	Specifies the tag name when triggering workflows by publishing tagged releases. (Requires alternate dispatch rules)
registry_token	true	The password or token used to authenticate with the registry

Example Usage

...
jobs:
  build-extension-catalog:
    name: Build and release Extension Catalog Image
    uses: rancher/dashboard/.github/workflows/build-extension-catalog.yml@master
    permissions:
      actions: write
      contents: read
      packages: write
    with:
      registry_target: ghcr.io
      registry_user: ${{ github.actor }}
    secrets: 
      registry_token: ${{ secrets.GITHUB_TOKEN }}

Versioning

Each workflow is targeting the master branch of rancher/dashboard by default. Depending on your @rancher/shell and Rancher instance versions, you will need to target the branch per release. For example, if running a Rancher instance version v2.7.7, you will need to target the release-2.7.7 branch:

...
jobs:
  build-extension-charts:
    name: Build and release Extension charts
    uses: rancher/dashboard/.github/workflows/build-extension-charts.yml@release-2.7.7

Warning: The reusable workflow was created after Rancher v2.7.5 - this means you will NOT be able to use these workflow files with this release or any previous releases.

Dispatching Configuration

As mentioned in the tagged_release property description, in order to have the workflow triggered by published releases the dispatch will need to be updated. This topic is covered in the Publishing section. To be concise, update the dispatch within the workflow file to execute the workflow on the released event of a release action:"

on:
  release:
    types: [released]

This will ensure that the workflow is only triggered when the tagged release is published and is not a draft release.

Extensive information on how to trigger workflows can be found in the Github documentation.