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.

converge:
  name: Converge
  runs-on: ubuntu-latest
  steps:

    - name: Checkout code
      uses: actions/checkout@v4
      with:
        fetch-depth: 0
    
    - name: Install werf
      uses: werf/actions/install@v2
      
    - name: Run script
      run: |
        . $(werf ci-env github --as-file) 
        werf converge
      env:
        WERF_KUBECONFIG_BASE64: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
        WERF_ENV: production
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

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@v2
  with:
    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@v2
  with:
    version: v2.1.0

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

- name: Checkout code
  uses: actions/checkout@v4
  with:
    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.

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: Converge
  runs-on: ubuntu-latest
  steps:

    - name: Checkout code
      uses: actions/checkout@v4
      with:
        fetch-depth: 0
    
    - name: Install werf
      uses: werf/actions/install@v2
    
    - name: cr login
      run: werf cr login -u ${{ secrets.REGISTRY_USER }} -p ${{ secrets.REGISTRY_TOKEN }} registry.example.com
    
    - name: converge
      run: werf converge
      env:
        WERF_KUBECONFIG_BASE64: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
        WERF_ENV: production
        WERF_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).

Apache License 2.0, see LICENSE