Deckhouse Modules Actions

Overview

This repository contains GitHub Actions workflows for building and deploying modules for the Deckhouse Kubernetes Platform.

Workflows

Workflow	Description
setup	Sets up the environment for building and deploying modules. This workflow must be run before any other workflows.
build	Builds the Deckhouse modules using the werf tool.
deploy	Deploys the Deckhouse modules to the one of selected release channels.
cve_scan	Trivy CVE Scan of module images. Documentation can be found here
svace_analyze	Include svace analyze action to analyze and import builds made with svace tool
translate-changelog	Translates Russian changelog files to English and creates a PR
merge-and-release	Merges a PR and creates a GitHub release with tag

Examples

All examples are located in the examples directory. They show how to use the workflows in different scenarios.

1. build.yaml — can be run for each PR commit and when a new release is created. Builds the modules and pushes them to the container registry.
2. deploy.yaml — can be run after releasing a new version of the modules. Deploys the modules to the selected release channel.
3. cve_scan.yaml — can run for each PR commit, manually and by push to main branch. Scans modules images for CVE and uploads reports to DefectDojo
4. svace_analyze.yaml — can be run after successfully build with svace tool. Analyze builds with svace analyze tool and imports to the Svacer.
5. translate-changelog.yml — runs on push to any branch. Translates Russian changelog files to English and creates a PR.
6. merge-and-release.yml — runs when a label is added to a PR. Merges the PR and creates a GitHub release.

Usage

To use these GitHub Action workflows in your own repository:

1. Copy the workflows (YAML files) from the .examples directory into your repository.

2. Adjust the workflow files based on your specific requirements and configurations.

3. Make sure to configure any necessary secrets or environment variables in your GitHub repository settings to enable secure deployment.

4. Trigger the workflows manually or automatically on each push, pull request, or any other event as needed.