Skip to content

Latest commit

 

History

History
129 lines (102 loc) · 6.02 KB

04-10-workflows.md

File metadata and controls

129 lines (102 loc) · 6.02 KB
Raw

GitHub Actions Workflows

Auto Update Chart and Resources

The goal of the workflow is to update the chart (module-chart/chart) to the newest version, render the resource templates from the newest chart, and create a PR with the changes. The workflow works on two shell scripts:

  • make-module-chart.sh - downloads the chart from the upstream, from the release tagged as latest and places it in the module-chart/chart.

  • make-module-resources.sh - uses Helm to render Kubernetes resources templates. As a base, it takes a chart from the module-chart/chart and values to override. After Helm finishes templating with the applied overrides, the generated resources are put into module-resources/apply. The resources used in the previous version but not used in the new version are placed under module-resource/delete. During the process of iterating over the sap-btp-service-operator resources, the script also keeps track of the GVKs to generate RBAC rules in btpoperator_controller.go which feeds into RBAC ClusterRole in the role.yaml resource kept in sync with make manifests just like any standard kubebuilder operator. The script excludes all resources with a Helm hook "pre-delete" as it is not necessary to apply it. Additionally, all excluded resources are added to the module-resources/excluded folder, where you can see what was excluded.

Both scripts are run from the workflow but can also be triggered manually from the developer's computer. They are placed under hack/update/.

To keep module-chart/chart in sync with the upstream, you must not apply any manual changes there.

Release Workflow

See BTP Manager Release Pipeline to learn more about the release workflow.

E2E Tests Workflow

This workflow uses the DEV artifact registry, tags the binary image and OCI module image with the PR number, and calls the reusable workflow. It is triggered by pull requests (PRs) on the main branch that change at least one of the following:

  • /.github directory content
  • /api directory content
  • /cmd directory content
  • /config directory content
  • /controllers directory content
  • /deployments directory content
  • /examples directory content
  • /hack directory content
  • /internal directory content
  • /module-chart directory content
  • /module-resources directory content
  • /scripts directory content
  • config.yaml file
  • Dockerfile file
  • go.mod file
  • go.sum file
  • main.go file
  • Makefile file
  • any *.go file
  • any *.sh file

Unit Tests Workflow

This workflow calls the reusable workflow. It is triggered by PRs on the main branch that change at least one of the following:

  • /.github directory content
  • /api directory content
  • /cmd directory content
  • /config directory content
  • /controllers directory content
  • /deployments directory content
  • /examples directory content
  • /hack directory content
  • /internal directory content
  • /module-chart directory content
  • /module-resources directory content
  • /scripts directory content
  • config.yaml file
  • Dockerfile file
  • go.mod file
  • go.sum file
  • main.go file
  • Makefile file
  • any *.go file
  • any *.sh file

Markdown Links Check Workflow

This workflow is triggered daily at midnight and by each PR on the main branch. It checks for dead links in the repository.

Govulncheck Workflow

This workflow runs the Govulncheck. It is triggered by PRs on the main branch that change at least one of the following:

  • /.github directory content
  • /api directory content
  • /cmd directory content
  • /config directory content
  • /controllers directory content
  • /deployments directory content
  • /examples directory content
  • /hack directory content
  • /internal directory content
  • /module-chart directory content
  • /module-resources directory content
  • /scripts directory content
  • config.yaml file
  • Dockerfile file
  • go.mod file
  • go.sum file
  • main.go file
  • Makefile file
  • any *.go file
  • any *.sh file

Reusable Workflows

There are reusable workflows created. Anyone with access to a reusable workflow can call it from another workflow.

E2E Tests

This workflow runs the E2E tests on the k3s cluster. You pass the following parameters from the calling workflow:

Parameter name Required Description
image-repo yes binary image registry reference
image-tag yes binary image tag
last-k3s-versions no number of most recent k3s versions to be used for tests, default = 1

The workflow:

  • Fetches the last-k3s-versions tag versions of k3s releases
  • Prepares the last-k3s-versions k3s clusters with the Docker registries using the list of versions from the previous step
  • Waits for the binary image to be ready in the registry
  • Runs the E2E tests on the clusters
  • Waits for all tests to finish

Unit Tests

This workflow runs the unit tests. No parameters are passed from the calling workflow (callee).

The workflow:

  • Checks out code and sets up the cache
  • Sets up the Go environment
  • Invokes make test