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.