Skip to main content
Version: 3.x.x

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:

PropertyExtension TypePermissionDescription
actionsCharts/CatalogwriteRequires write to cancel a workflow.
contentsCharts*/Catalogwrite*/readRequires 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.
deploymentsChartswriteRequires write when deploying gh-pages.
packagesCatalogwriteRequires write when a catalog image is created to create the package.
pagesChartswriteRequires write to request and create page builds for the deployment.

Extension Chart Inputs

PropertyRequiredDescription
permissionstrueThis gives the workflow permissions to checkout, build, and push to the repository.
target_branchtrueThe Github branch target for the extension build assets
tagged_releasefalseSpecifies 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

PropertyRequiredDescription
permissionstrueThis gives the workflow permissions to checkout, build, and push to the registry.
registry_targettrueThe container registry to publish the catalog image
registry_usertrueThe username connected to the container registry
tagged_releasefalseSpecifies the tag name when triggering workflows by publishing tagged releases. (Requires alternate dispatch rules)
registry_tokentrueThe 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.