GitHub Action
werf
This action set allows you to organize CI/CD with GitHub Actions and werf. The set consists of several independent and complex actions:
Each action combines all the necessary steps in itself, and logic may be divided into environment setup and launching the corresponding command.
Ready-to-use GitHub Actions Workflows for different CI/CD workflows are available here.
Also, there is another action — werf/actions/install. With this action, the user can install werf and use binary within job steps for own purposes.
When using actions, select the version corresponding to the required MAJOR.MINOR version of werf:
# Run converge using actual werf version within 1.1 alpha channel.
- uses: werf/actions/[email protected]
# Run converge using actual werf version within 1.2 alpha channel.
- uses: werf/actions/[email protected]By default, all actions install actual werf version within 1.2 alpha channel (more details about channels, werf release cycle and compatibility promise here).
Using the channel input the user can switch the release channel.
This is recommended approach to be up-to-date and to use actual werf version without changing configurations.
- uses: werf/actions/[email protected]
with:
channel: alphaWithal, it is not necessary to work within release channels, and the user might specify certain werf version with version input.
- uses: werf/actions/[email protected]
with:
version: v1.2.9This is the step where an action:
- sets the defaults for werf command options based on GitHub Workflow environment variables (e.g. container repository address to the
WERF_REPOenvironment variable using the following pattern:ghcr.io/$GITHUB_REPOSITORY/<project-from-werf.yaml>). - performs docker login to
ghcr.iousing thegithub-tokeninput (only ifghcr.ioused asWERF_REPO).
The
github-tokeninput is optional, and the input is there in case you need to use a non-default token. By default, an action will use the token provided to your workflow.
The kubeconfig may be used for deployment, cleanup, distributed locks and caches. Thus, the configuration should be added before step with the action or passed as base64 encoded data with kube-config-base64-data input:
-
Prepare kubeconfig (e.g.
cat ~/.kube/config | base64) and save in GitHub Secrets (e.g. with nameKUBE_CONFIG_BASE64_DATA). -
Pass secret with
kube-config-base64-datainput:- uses: werf/actions/[email protected] with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
All werf options can be defined with environment variables:
- uses: werf/actions/[email protected]
env:
WERF_LOG_VERBOSE: "on" # The same as using the option --log-verbose=on.An action generates the default container repository address and performs docker login to the registry within werf ci-env step.
For cleanup action, the user needs to create personal access token with read:packages and delete:packages scope and uses it as the WERF_REPO_GITHUB_TOKEN environment variable or the github-token input. It is recommended to store the token as a secret.
- uses: werf/actions/[email protected]
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env:
WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_CLEANUP_PAM }}An arbitrary container repository can be specified with the WERF_REPO and WERF_REPO_CONTAINER_REGISTRY environment variables. For instance, steps for GCR:
- name: Login to GCR
uses: docker/login-action@v1
with:
registry: gcr.io
username: _json_key
password: ${{ secrets.GCR_JSON_KEY }}
- uses: werf/actions/[email protected]
env:
WERF_REPO: "gcr.io/company/app"
WERF_REPO_CONTAINER_REGISTRY: "gcr"To learn more about how to work with the different container registries, see the appropriate article in the werf documentation.
converge:
name: Converge
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Converge
uses: werf/actions/[email protected]
with:
env: production
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}dismiss:
name: Dismiss
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Dismiss
uses: werf/actions/[email protected]
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env: productionrun:
name: Run
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Run
uses: werf/actions/[email protected]
with:
image: backend
args: rails server
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env:
WERF_DOCKER_OPTIONS: "-d -p 3000:3000"cleanup:
name: Cleanup
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Fetch all history for all tags and branches
run: git fetch --prune --unshallow
- name: Cleanup
uses: werf/actions/[email protected]
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env:
WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_CLEANUP_PAM }}werf:
name: werf
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Install werf CLI
uses: werf/actions/[email protected]
# For deploy and distributed locks.
- name: Create kube config
run: |
KUBECONFIG=$(mktemp -d)/config
base64 -d <(printf "%s" $KUBE_CONFIG_BASE64_DATA) > $KUBECONFIG
echo KUBECONFIG=$KUBECONFIG >> $GITHUB_ENV
env:
KUBE_CONFIG_BASE64_DATA: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
- name: Run werf commands
run: |
source $(werf ci-env github --as-file)
werf render
werf converge
env:
GITHUB_TOKEN: ${{ github.token }}
WERF_ENV: productionApache License 2.0, see LICENSE