5.4 KiB

Raw Blame History

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.

5.4 KiB Raw Blame History