___

This action allows you to organize CI/CD with GitHub Actions and werf.

Ready-to-use GitHub Actions Workflows for different CI/CD workflows are available here.

How to use

converge:
name: Convergeruns-on: ubuntu-lateststeps:
- name: Checkout codeuses: actions/checkout@v4with:
fetch-depth: 0
- name: Install werfuses: werf/actions/install@v2
- name: Run scriptrun: | . $(werf ci-env github --as-file)  werf convergeenv:
WERF_KUBECONFIG_BASE64: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}WERF_ENV: productionGITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Versioning

When using action, select the version corresponding to the required MAJOR version of werf.

By default, the action installs actual werf version within 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/install@v2with:
channel: alpha

Withal, it is not necessary to work within release channels, and the user might specify certain werf version with version input.

- uses: werf/actions/install@v2with:
version: v2.1.0

FAQ

werf always rebuilds images on new commit

Make sure to use fetch-depth: 0 setting in the checkout action, like follows:

- name: Checkout codeuses: actions/checkout@v4with:
fetch-depth: 0

By default, fetch-depth set to 1 which disables git history when checking out code. werf cache selection algorithm uses git history to determine whether some image bound to some commit could be used as a cache when building current commit (current commit should be descendant to the cache commit).

Setting fetch-depth to 0 enables full fetch of git history, and it is a recommended approach. It is also possible to limit fetch history with some decent number of commits, which would enable images caching limited to that number of commits, but this would have a negative impact on cache reproducibility.

Working with container registry

If there is a need to perform authorization using custom credentials or in an external container registry, then you have to use a ready-made action tailored to your container registry (or just run werf cr login).

converge:
name: Convergeruns-on: ubuntu-lateststeps:
- name: Checkout codeuses: actions/checkout@v4with:
fetch-depth: 0
- name: Install werfuses: werf/actions/install@v2
- name: cr loginrun: werf cr login -u ${{ secrets.REGISTRY_USER }} -p ${{ secrets.REGISTRY_TOKEN }} registry.example.com
- name: convergerun: werf convergeenv:
WERF_KUBECONFIG_BASE64: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}WERF_ENV: productionWERF_REPO: registry.example.com/repo

Environment variables WERF_REPO and GITHUB_TOKEN for converge should only be used if building images is required otherwise they can be omitted

In the simplest case, if an integrated GitHub Packages-like container registry is used, then the authorization is performed automatically when the werf ci-env command is invoked. This command is run with several required arguments such as GitHub environment variables, the GITHUB_TOKEN secret (you have to explicitly declare it).

Building multi-platform images

To build multi-platform images or customize the build environment, you can use docker/setup-buildx-action@v3.

jobs:
build:
runs-on: ubuntu-lateststeps:
- name: Checkoutuses: actions/checkout@v4with:
fetch-depth: 0
- name: Set up Docker Buildxuses: docker/setup-buildx-action@v3
- name: Install werfuses: werf/actions/install@v2
- name: cr loginrun: werf cr login -u ${{ secrets.REGISTRY_USER }} -p ${{ secrets.REGISTRY_TOKEN }} registry.example.com
- name: convergerun: | . $(werf ci-env github --as-file) werf convergeenv:
WERF_KUBECONFIG_BASE64: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}WERF_ENV: production

No additional configuration is required, and QEMU is automatically used for cross-platform builds.

License

Apache License 2.0, see LICENSE