The repository for reusable workflows.
Detailed description of existing workflows can be found here Index of Workflow Documentation
- qubership-workflow-hub
Below is the short description of how to implement common workflows in any Netcracker repository. All necessery secrets and variables for common workflows are already present on organization level, no additional settings or configurations are required.
| Name | Purpose |
|---|---|
| secrets.GITHUB_TOKEN | Automatic token authentication (see more here) |
| secrets.CLA_ACCESS_TOKEN | Used by CLA workflow to access cla storage |
| secrets.MAVEN_USER | Username to authenticate in Maven Central repository to publish released artifacts |
| secrets.MAVEN_PASSWORD | User token to authenticate in Maven Central repository to publish released artifacts |
| secrets.MAVEN_GPG_PRIVATE_KEY | GPG private key to sign artefacts (jar, pom etc) to publish them into Maven Central |
| secrets.MAVEN_GPG_PASSPHRASE | GPG private key passphrase |
| secrets.PYPI_API_TOKEN | Token to publish packages to PYPI registry |
| secrets.GH_ACCESS_TOKEN | Token for "tech user" with extended acess rights |
| secrets.WORKFLOWS_TOKEN | Classic Token with workflow scope |
| secrets.SONAR_TOKEN | Token to access SonarQube |
| secrets.GH_RWD_PACKAGE_TOKEN | Token with access to GitHub packages |
There are several reusable workflows which should be added into every Netcracker repository, see the description below.
Important Consideration for Fork and Sync
If this repository is forked and synced via pull requests, some workflows (such as the auto-labeler) will not function properly due to missing token in fork repository.
Consider submitting pull requests to the target branch. details here
- CLA: https://github.com/Netcracker/.github/blob/main/workflow-templates/cla.yaml
- Automatic PR Labeler: https://github.com/Netcracker/.github/blob/main/workflow-templates/automatic-pr-labeler.yaml
- Link Checker: https://github.com/Netcracker/.github/blob/main/workflow-templates/link-checker.yaml
- Assign PR: https://github.com/Netcracker/.github/blob/main/workflow-templates/pr-assigner.yml
- Lint Code Base: https://github.com/Netcracker/.github/blob/main/workflow-templates/super-linter.yaml
- Profanity filter: https://github.com/Netcracker/.github/blob/main/workflow-templates/profanity-filter.yaml
- Lint PR Title: https://github.com/Netcracker/.github/blob/main/workflow-templates/pr-lint-title.yaml
- Conventional Commits PR Check: https://github.com/Netcracker/.github/blob/main/workflow-templates/pr-conventional-commits.yaml
The action for CLA "signing" for contributors.
More info about underlying GitHub Action can be found here contributor-assistant
To add the CLA signing into your repository just copy the prepared file into .github/workflows directory of your repository.
The CLA_ACCESS_TOKEN used in the workflow is defined on organization level then you can use it in any Netcracker/* repository.
This workflow executes several linters on changed files based on languages used in your codebase whenever you push a code or open a pull request. You can adjust the behavior by adding/modifying configuration files for super-linter itself and for individual linters.
For more information, see: Super-linter
Configuration file for super-linter example: .github/super-linter.env Configuration files for individual linters should be placed in .github/linters
To add the super-linter workflow into your repository just copy the prepared file into .github/workflows directory of your repository.
The action to check PRs/issues comments on profany words.
More info about underlying GitHub Action can be found here profanity-filter
To add the profanity filter into your repository just copy the prepared file into .github/workflows directory of your repository.
The workflow automatically label PR on it's open/reopen events. It checks all the commit messages for certain words and apply corresponding labels to PR. Those labels used by Maven project release workflow to generate release notes.
Create a new workflow in your repository. Copy the prepared file into .github/workflows directory of your repository.
Create a new configuration file .github/auto-labeler-config.yaml. Copy prepared file into .github directory of your repository.
The configuration file from previous step defines the next rules for PR labeling based on words in commit messages:
| Commit message word(s) | Label |
|---|---|
| 'FIX', 'Fix', 'fix', 'FIXED', 'Fixed', 'fixed' | bug |
| 'FEATURE', 'Feature', 'feature', 'FEAT', 'Feat', 'feat' | enhancement |
| 'BREAKING CHANGE', 'BREAKING', 'MAJOR' | breaking-change |
| 'refactor','Refactor' | refactor |
| 'doc','docs','document','documentation' | documentation |
| 'build','rebuild' | build |
| 'config', 'conf', 'cofiguration', 'configure' | config |
Labels on PRs used to generate release notes for GitHub releases. You can edit labels configuration and release notes generation template to extend or improve the default ones.
The workflow will check commits in pull request if they follow Conventional Commits strategy.
More info on underlying GitHub Action can be found here Conventional Commits GitHub Action
To add the workflow into your repository copy the prepared file into .github/workflows directory of your repository.
The workflow will check pull request title if it follows Conventional Commits strategy.
More info on underlying GitHub Action can be found here Semantic Pull Request.
To add the workflow into your repository copy the prepared file into .github/workflows directory of your repository.
Maven project release workflow is used to make a GitHub release and publish released artifacts into Maven Central or Github packages. The workflow consists of several sequential jobs:
- Checks if the tag already exists.
- Builds current snapshot versions (dry run step)
- Prepares release using Maven (maven-release-plugin)
- Builds and deploys the project using Maven (maven-release-plugin).
- Builds and publishes a Docker image if there is Dockerfile.
- Create GitHub release
To make it use one need to do several preparations in the project.
First of all please make sure the pom.xml file prepared to build source code and java doc jars alongside with main artifact. You need to sign all publishing artifacts with PGP key too. The instruction on how to do it can be found here Prepare your project to publish into Maven Central
Copy the prepared file into .github/workflows directory of your repository.
This workflow is designed to be run manually. It has four input parameters on manual execution:
Version type to release-- a string represents version type to release:patch,minorormajorMaven profile to use-- maven profile can becentralorgithub.Additional maven arguments to pass-- additional arguments to pass tomvncommand.Build Docker image-- build and publish docker image to GitHub packages if Dockerfile exists
Upload prepared configuration file to your repository in .github folder. You can customize it in future for your needs.
The workflow needs several secrets to be prepared to work properly. For Netcracker repositories all of them already prepared, configured and available for use. You can find them in table The organization level secrets and vars used in actions. Detailed instructions on how to generate a GPG key and set up secrets in a GitHub repository can be found in this document.
Python project release workflow is used to make a GitHub release and publish released artifacts into PyPi.
Copy the prepared file into .github/workflows directory of your repository.
This workflow is designed to be run manually. It has six input parameters on manual execution:
Specify version (optional)-- a string represents the version number (optional). If empty the version number will be cretad automatically.Python version to use-- a string represents Python version to use to build artifacts (e.g.,3.11)Poetry version bump-- which part of SemVer version to bump (e.g.,patch,minor,major)'Additional poetry build parameters-- additional poetry build parametersRun pytest-- to run pytests or not (true/false).Parameters for pytest-- additional parameters to pass into pytests. By default value is--maxfail=3 -v
The Python Release workflow require PyPi API token. You need to get it from PyPi and add into your repositories Actions secrets. The name of the secret should be PYPI_API_TOKEN.
The step exactly the same as Step 3: Add configuration file for GitHub release for maven release workflow.
Docker project release workflow is used to make a GitHub release and publish released artifacts into GitHub docker registry. The workflow consists of several sequential jobs:
- Checks if the tag already exists.
- Ceates a new tag with name "v${version}.
- Builds and publishes a Docker image.
- Create GitHub release
Copy the prepared file into .github/workflows directory of your repository.
This workflow is designed to be run manually. It has four input parameters on manual execution:
Release version-- a string represents version number of the releaseDry run-- if selected the workflow will go through all the steps, but will not publish anything.
The step exactly the same as Step 3: Add configuration file for GitHub release for maven release workflow.
The underlying reusable workflow accepts more input parameters then the release workflow. For simplicity the template forkflow provides reasonable defaults which are sutable in most cases. The default usage scenario assumes the following conditions:
- The resulting artifact name is the same as repository name
- Artifact built from tag name equal to
v${version} - There are no pre-built artifacts. It means that Dockerfile has a "build from sources" stage
- There is only one Dockerfile and it placed in the root of repository
- Build context for Dockerfile is
.
If the default case isn't your's -- please read the detailed description of the input parameters and customize them according to your needs.
The workflow will check licenses of all dependencies if they are in scope of allowlist.
More info about used tool can be found here wwhrd
Copy the prepared file into .github/workflows directory of your repository.
Copy the prepared file into root directory of your repository.