Merge pull request #57 from werf/upd-readme

[1.1] docs: add notice about fetch-depth into README

.github/workflows/test.yaml

@@ -12,7 +12,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     steps:
       - name: Checkout code
-        uses: actions/checkout@v4
+        uses: actions/checkout@v2
         with:
           fetch-depth: 0
 
@@ -31,13 +31,13 @@ jobs:
     steps:
 
       - name: Checkout code
-        uses: actions/checkout@v4
+        uses: actions/checkout@v2
         with:
           fetch-depth: 0
 
       - name: Install
         uses: ./install
         with:
-          version: v2.31.1
+          version: v1.1.23+fix50
 
       - run: werf version

README.md

@@ -3,47 +3,46 @@
 </p>
 ___
 
-This action allows you to organize CI/CD with GitHub Actions and [werf](https://github.com/werf/werf).
+This action set allows you to organize CI/CD with GitHub Actions and [werf](https://github.com/werf/werf). The set consists of several independent and complex actions:
 
-**Ready-to-use GitHub Actions Workflows** for different CI/CD workflows are available [here](https://werf.io/guides/nodejs/400_ci_cd_workflow/040_github_actions.html).
+- [werf/actions/converge](https://github.com/werf/actions/tree/v1.1/converge)
+- [werf/actions/build-and-publish](https://github.com/werf/actions/tree/v1.1/build-and-publish)
+- [werf/actions/build](https://github.com/werf/actions/tree/v1.1/build)
+- [werf/actions/publish](https://github.com/werf/actions/tree/v1.1/build)
+- [werf/actions/deploy](https://github.com/werf/actions/tree/v1.1/deploy)
+- [werf/actions/dismiss](https://github.com/werf/actions/tree/v1.1/dismiss)
+- [werf/actions/run](https://github.com/werf/actions/tree/v1.1/run)
+- [werf/actions/cleanup](https://github.com/werf/actions/tree/v1.1/cleanup)
 
-## How to use
+Each action combines all the necessary steps in itself and logic may be divided into environment setup and launching the corresponding command. 
 
-```yaml
+**Ready-to-use GitHub Actions Workflows** for different CI/CD workflows are available [here](https://werf.io/v1.1-alpha/documentation/guides/github_ci_cd_integration.html#complete-set-of-configurations-for-ready-made-workflows).
-converge:
-  name: Converge
-  runs-on: ubuntu-latest
-  steps:
 
-    - name: Checkout code
+> Also, there is another action — [werf/actions/install](https://github.com/werf/actions/tree/v1.1/install). With this action a user can just install werf and use binary within job steps for own purposes
-      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 }}
-```
 
 ## Versioning
 
-When using action, select the version corresponding to the required `MAJOR` version of werf.
+When using actions, select the version corresponding to the `MAJOR.MINOR` 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](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
-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.
 
 ```yaml
-- uses: werf/actions/install@v2
+# run converge with actual werf version for 1.1 alpha channel
+- uses: werf/actions/converge@v1.1
+
+# run converge with actual werf version for 1.2 alpha channel
+- uses: werf/actions/converge@v1.2
+```
+
+## Environment setup in details
+
+### werf binary setup
+
+By default, all actions setup actual werf version for 1.1 alpha channel (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+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
+  
+```yaml
+- uses: werf/actions/converge@v1.1
   with:
     channel: alpha
 ```
@@ -51,31 +50,63 @@ Using the `channel` input the user can switch the release channel.
 Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
 
 ```yaml
-- uses: werf/actions/install@v2
+- uses: werf/actions/converge@v1.1
   with:
-    version: v2.1.0
+    version: v1.1.23
 ```
 
-## FAQ
+### kubeconfig setup (*optional*)
 
-### werf always rebuilds images on new commit
+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:
 
-Make sure to use `fetch-depth: 0` setting in the checkout action, like follows:
+* Prepare _kubeconfig_ (e.g. `cat ~/.kube/config | base64`) and save in GitHub Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/build-and-publish@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
 
 ```yaml
-- name: Checkout code
+- uses: werf/actions/build-and-publish@v1.1
-  uses: actions/checkout@v4
+  env:
-  with:
+    WERF_LOG_VERBOSE: "on"
-    fetch-depth: 0
+    WERF_TAG_CUSTOM_TAG1: tag1
+    WERF_TAG_CUSTOM_TAG2: tag2
 ```
 
-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).
+## Working with container registry
 
-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.
+Due to the fact that the new GitHub container registry (`ghcr.io`) does not currently support removal, all actions default to the old one (`docker.pkg.github.com`).
 
-### Working with container registry
+If necessary, the user can define an arbitrary container registry using the `WERF_REPO` and `WERF_REPO_IMPLEMENTATION` environment variables.
 
-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`).
+```yaml
+- uses: werf/actions/converge@v1.1
+  env:
+    WERF_REPO: "gcr.io/company/app"
+    WERF_REPO_IMPLEMENTATION: "gcr"
+```
+
+To learn how to work with the different container registries, see the corresponding [article in the werf documentation](https://werf.io/v1.1-alpha/documentation/reference/working_with_docker_registries.html).
+
+## Examples
+
+### converge
 
 ```yaml
 converge:
@@ -84,28 +115,164 @@ converge:
   steps:
 
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
       with:
         fetch-depth: 0
 
-    - name: Install werf
+    - name: Converge
-      uses: werf/actions/install@v2
+      uses: werf/actions/converge@v1.1
-    
+      with:
-    - name: cr login
+        env: production
-      run: werf cr login -u ${{ secrets.REGISTRY_USER }} -p ${{ secrets.REGISTRY_TOKEN }} registry.example.com
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
-    
-    - 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 
+### build, publish and deploy
 
-In the simplest case, if an [integrated GitHub Packages-like container registry](https://help.github.com/en/packages/using-github-packages-with-your-projects-ecosystem/configuring-docker-for-use-with-github-packages) 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](https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#about-the-github_token-secret) (you have to explicitly declare it).
+```yaml
+build-and-publish:
+  name: Build and Publish
+  runs-on: ubuntu-latest
+  steps:
 
-## License
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Build and Publish
+      uses: werf/actions/build-and-publish@v1.1
+      with:
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+
+deploy:
+  name: Deploy
+  needs: build-and-publish
+  runs-on: ubuntu-latest
+  steps:
+
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Deploy
+      uses: werf/actions/deploy@v1.1
+      with:
+        env: production
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+```
+
+### dismiss
+
+```yaml
+dismiss: 
+  name: Dismiss
+  runs-on: ubuntu-latest
+  steps:
+  
+    - name: Checkout code
+      uses: actions/checkout@v2
+
+    - name: Dismiss
+      uses: werf/actions/dismiss@v1.1
+      with:
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+        env: production
+```
+
+### run 
+
+```yaml
+run: 
+  name: Run
+  runs-on: ubuntu-latest
+  steps:
+  
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Run
+      uses: werf/actions/run@v1.1
+      with:
+        image: backend
+        args: rails server
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+      env:
+        WERF_DOCKER_OPTIONS: "-d -p 3000:3000"
+```
+
+### cleanup
+
+```yaml
+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/cleanup@v1.1
+      with:
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+```
+
+### install
+
+```yaml
+werf:
+  name: werf 
+  runs-on: ubuntu-latest
+  steps:
+  
+    - name: Checkout code  
+      uses: actions/checkout@v2
+
+    - name: Install werf CLI  
+      uses: werf/actions/install@v1.1
+    
+    # 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 build-and-publish
+        werf deploy
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
+        WERF_ENV: production
+```
+
+# FAQ
+
+## werf always rebuilds images on new commit
+
+Make sure to use `fetch-depth: 0` setting in the checkout action, like follows:
+
+```
+- name: Checkout code
+  uses: actions/checkout@v2
+    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.
+
+# License
 
 Apache License 2.0, see [LICENSE](LICENSE)

action.yml

@@ -23,5 +23,5 @@ inputs:
     description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'converge/index.js'

build-and-publish/README.md

@@ -0,0 +1,101 @@
+<p align="center">
+  <img src="https://github.com/werf/werf/raw/master/docs/images/werf-logo.svg?sanitize=true" style="max-height:100%;" height="175">
+</p>
+___
+
+The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf build-and-publish`.
+
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://github.com/werf/werf#backward-compatibility-promise)). 
+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
+  
+```yaml
+- uses: werf/actions/build-and-publish@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/build-and-publish@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/build-and-publish@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/build-and-publish@v1.1
+  env:
+    WERF_LOG_VERBOSE: "on"
+    WERF_TAG_CUSTOM_TAG1: tag1
+    WERF_TAG_CUSTOM_TAG2: tag2
+```
+
+## Inputs
+
+```yaml
+channel:
+  description: 'The one of the following channel: alpha, beta, ea, stable, rock-solid'
+  default: 'alpha'
+  required: false
+version:
+  description: 'The certain version'
+  required: false
+github-token:
+  description: 'The GitHub token used to login and to interact with Docker Github Packages'
+  default: ${{ github.token }}
+  required: false
+kube-config-base64-data:
+  description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
+  required: false
+```
+
+## Example
+
+```yaml
+build-and-publish: 
+  name: Build and Publish
+  runs-on: ubuntu-latest
+  steps:
+  
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Build and Publish  
+      uses: werf/actions/build-and-publish@v1.1
+      with:
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+```

build-and-publish/action.yml

@@ -0,0 +1,24 @@
+name: werf build-and-publish
+author: 'Flant'
+description: 'Prepare the environment and perform image building and publishing with werf'
+branding:
+  color: blue
+  icon: anchor
+inputs:
+  channel:
+    description: 'The one of the following channel: alpha, beta, ea, stable, rock-solid'
+    default: 'alpha'
+    required: false
+  version:
+    description: 'The certain version'
+    required: false
+  github-token:
+    description: 'The GitHub token used to login and to interact with Docker Github Packages'
+    default: ${{ github.token }}
+    required: false
+  kube-config-base64-data:
+    description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
+    required: false
+runs:
+  using: 'node12'
+  main: 'index.js'

build/README.md

@@ -5,6 +5,63 @@ ___
 
 The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf build`.
 
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+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
+  
+```yaml
+- uses: werf/actions/build@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/build@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/build@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/build@v1.1
+  env:
+    WERF_LOG_VERBOSE: "on"
+    WERF_TAG_CUSTOM_TAG1: tag1
+    WERF_TAG_CUSTOM_TAG2: tag2
+```
+
 ## Inputs
 
 ```yaml
@@ -33,12 +90,12 @@ build:
   steps:
   
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
       with:
         fetch-depth: 0
 
     - name: Build
-      uses: werf/actions/build@v2
+      uses: werf/actions/build@v1.1
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
 ```

build/action.yml

@@ -20,5 +20,5 @@ inputs:
     description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'index.js'

cleanup/README.md

@@ -5,6 +5,61 @@ ___
 
 The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf cleanup`.
 
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+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
+  
+```yaml
+- uses: werf/actions/cleanup@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/cleanup@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/cleanup@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/cleanup@v1.1
+  env:
+    WERF_LOG_VERBOSE: "on"
+```
+
 ## Inputs
 
 ```yaml
@@ -33,15 +88,13 @@ cleanup:
   steps:
   
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
 
     - name: Fetch all history for all tags and branches
       run: git fetch --prune --unshallow
 
     - name: Cleanup
-      uses: werf/actions/cleanup@v2
+      uses: werf/actions/cleanup@v1.1
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
-      env:
-        WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_CLEANUP_PAM }}
 ```

cleanup/action.yml

@@ -20,5 +20,5 @@ inputs:
     description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'index.js'

converge/README.md

@@ -5,6 +5,63 @@ ___
 
 The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf converge`.
 
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+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
+  
+```yaml
+- uses: werf/actions/converge@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/converge@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/converge@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/converge@v1.1
+  with:
+    env: production
+  env:
+    WERF_LOG_VERBOSE: "on"
+```
+
 ## Inputs
 
 ```yaml
@@ -36,12 +93,12 @@ converge:
   steps:
   
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
       with:
         fetch-depth: 0
 
     - name: Converge
-      uses: werf/actions/converge@v2
+      uses: werf/actions/converge@v1.1
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
         env: production

converge/action.yml

@@ -12,9 +12,9 @@ inputs:
   version:
     description: 'The certain version'
     required: false
-  env: # TODO: Remove this deprecated werf option, which is not required anymore (use WERF_ENV variable instead)
+  env:
     description: 'Specific deployment environment'
-    required: false
+    required: true
   github-token:
     description: 'The GitHub token used to login and to interact with Docker Github Packages'
     default: ${{ github.token }}
@@ -23,5 +23,5 @@ inputs:
     description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'index.js'

deploy/README.md

@@ -0,0 +1,105 @@
+<p align="center">
+  <img src="https://github.com/werf/werf/raw/master/docs/images/werf-logo.svg?sanitize=true" style="max-height:100%;" height="175">
+</p>
+___
+
+The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf deploy`.
+
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://github.com/werf/werf#backward-compatibility-promise)). 
+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
+  
+```yaml
+- uses: werf/actions/deploy@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/deploy@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/deploy@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/deploy@v1.1
+  with:
+    env: production
+  env:
+    WERF_LOG_VERBOSE: "on"
+```
+
+## Inputs
+
+```yaml
+channel:
+  description: 'The one of the following channel: alpha, beta, ea, stable, rock-solid'
+  default: 'alpha'
+  required: false
+version:
+  description: 'The certain version'
+  required: false
+env:
+  description: 'Specific deployment environment'
+  required: true
+github-token:
+  description: 'The GitHub token used to login and to interact with Docker Github Packages'
+  default: ${{ github.token }}
+  required: false
+kube-config-base64-data:
+  description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
+  required: false
+```
+
+## Example
+
+```yaml
+deploy: 
+  name: Deploy
+  runs-on: ubuntu-latest
+  steps:
+  
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Deploy
+      uses: werf/actions/deploy@v1.1
+      with:
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+        env: production
+```

deploy/action.yml

@@ -0,0 +1,27 @@
+name: werf build-and-publish
+author: 'Flant'
+description: 'Prepare the environment and perform deployment with werf'
+branding:
+  color: blue
+  icon: anchor
+inputs:
+  channel:
+    description: 'The one of the following channel: alpha, beta, ea, stable, rock-solid'
+    default: 'alpha'
+    required: false
+  version:
+    description: 'The certain version'
+    required: false
+  env:
+    description: 'Specific deployment environment'
+    required: true
+  github-token:
+    description: 'The GitHub token used to login and to interact with Docker Github Packages'
+    default: ${{ github.token }}
+    required: false
+  kube-config-base64-data:
+    description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
+    required: false
+runs:
+  using: 'node12'
+  main: 'index.js'

dismiss/README.md

@@ -5,6 +5,63 @@ ___
 
 The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf dismiss`.
 
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+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
+  
+```yaml
+- uses: werf/actions/converge@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/converge@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/converge@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/converge@v1.1
+  with:
+    env: production
+  env:
+    WERF_LOG_VERBOSE: "on"
+```
+
 ## Inputs
 
 ```yaml
@@ -36,10 +93,10 @@ dismiss:
   steps:
   
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
 
     - name: Dismiss
-      uses: werf/actions/dismiss@v2
+      uses: werf/actions/dismiss@v1.1
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
         env: production

dismiss/action.yml

@@ -12,9 +12,9 @@ inputs:
   version:
     description: 'The certain version'
     required: false
-  env: # TODO: Remove this deprecated werf option, which is not required anymore (use WERF_ENV variable instead)
+  env:
     description: 'Specific deployment environment'
-    required: false
+    required: true
   github-token:
     description: 'The GitHub token used to login and to interact with Docker Github Packages'
     default: ${{ github.token }}
@@ -23,5 +23,5 @@ inputs:
     description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'index.js'

install/README.md

@@ -3,13 +3,13 @@
 </p>
 ___
  
-By default, all actions setup actual werf version for 1.2 alpha channel (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
 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
   
 ```yaml
-- uses: werf/actions/install@v2
+- uses: werf/actions/install@v1.1
   with:
     channel: alpha
 ```
@@ -17,9 +17,9 @@ Using the `channel` input the user can switch the release channel.
 Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
 
 ```yaml
-- uses: werf/actions/install@v2
+- uses: werf/actions/install@v1.1
   with:
-    version: v2.1.0
+    version: v1.1.23
 ```
 
 ## Inputs
@@ -43,12 +43,12 @@ werf:
   steps:
   
     - name: Checkout code  
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
 
     - name: Install werf CLI  
-      uses: werf/actions/install@v2
+      uses: werf/actions/install@v1.1
     
-    # For deploy and distributed locks.
+    # for deploy and distributed locks
     - name: Create kube config
       run: |
         KUBECONFIG=$(mktemp -d)/config
@@ -60,9 +60,9 @@ werf:
     - name: Run werf commands
       run: |
         source $(werf ci-env github --as-file)
-        werf render
+        werf build-and-publish
-        werf converge
+        werf deploy
       env:
-        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        GITHUB_TOKEN: ${{ github.token }}
         WERF_ENV: production
 ```

install/action.yml

@@ -1,6 +1,6 @@
 name: Install werf CLI
 author: 'Flant'
-description: 'Install werf CLI'
+description: 'Install actual channel werf version, like multiwerf does, or specified one'
 branding:
   color: blue
   icon: anchor
@@ -17,5 +17,5 @@ inputs:
     default: '0'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'index.js'

pack.sh

@@ -1,3 +1,3 @@
 #!/bin/bash -e
 
-for pkg in build cleanup converge dismiss install run; do ncc build src/$pkg.ts -o $pkg; done
+for pkg in build build-and-publish cleanup converge deploy dismiss install publish run; do ncc build src/$pkg.ts -o $pkg; done

package.json

@@ -1,14 +1,14 @@
 {
   "name": "werf-actions",
-  "version": "1.2.1",
+  "version": "1.1.1",
   "description": "",
   "main": "lib",
   "dependencies": {
-    "@actions/core": "^1.9.1",
+    "@actions/core": "^1.6.0",
-    "@actions/github": "^6.0.0",
+    "@actions/github": "^5.0.0",
     "@actions/tool-cache": "^1.7.1",
     "dotenv": "10.0.x",
-    "semver": "^7.5.2",
+    "semver": "^7.3.5",
     "string-argv": "^0.3.1",
     "superagent": "^6.1.0",
     "tmp": "^0.2.1",
@@ -25,7 +25,7 @@
     "eslint": "^7.32.0",
     "eslint-plugin-github": "^4.3.2",
     "js-yaml": "^3.13.1",
-    "node-fetch": ">=3.2.10",
+    "node-fetch": ">=2.6.1",
     "prettier": "^1.19.1",
     "typescript": "^3.6.4"
   },
@@ -34,7 +34,7 @@
     "format": "prettier --write **/*.ts",
     "format-check": "prettier --check **/*.ts",
     "lint": "eslint src/**/*.ts",
-    "pack": "./pack.sh",
+    "pack": "pack.sh",
     "all": "npm run build && npm run format && npm run lint && npm run pack"
   },
   "repository": {

publish/README.md

@@ -0,0 +1,101 @@
+<p align="center">
+  <img src="https://github.com/werf/werf/raw/master/docs/images/werf-logo.svg?sanitize=true" style="max-height:100%;" height="175">
+</p>
+___
+
+The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf publish`.
+
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://github.com/werf/werf#backward-compatibility-promise)). 
+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
+  
+```yaml
+- uses: werf/actions/publish@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/publish@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/publish@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/publish@v1.1
+  env:
+    WERF_LOG_VERBOSE: "on"
+    WERF_TAG_CUSTOM_TAG1: tag1
+    WERF_TAG_CUSTOM_TAG2: tag2
+```
+
+## Inputs
+
+```yaml
+channel:
+  description: 'The one of the following channel: alpha, beta, ea, stable, rock-solid'
+  default: 'alpha'
+  required: false
+version:
+  description: 'The certain version'
+  required: false
+github-token:
+  description: 'The GitHub token used to login and to interact with Docker Github Packages'
+  default: ${{ github.token }}
+  required: false
+kube-config-base64-data:
+  description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
+  required: false
+```
+
+## Example
+
+```yaml
+publish: 
+  name: Publish
+  runs-on: ubuntu-latest
+  steps:
+  
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        fetch-depth: 0
+
+    - name: Publish
+      uses: werf/actions/publish@v1.1
+      with:
+        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+```

publish/action.yml

@@ -0,0 +1,24 @@
+name: werf publish
+author: 'Flant'
+description: 'Prepare the environment and perform image publishing with werf'
+branding:
+  color: blue
+  icon: anchor
+inputs:
+  channel:
+    description: 'The one of the following channel: alpha, beta, ea, stable, rock-solid'
+    default: 'alpha'
+    required: false
+  version:
+    description: 'The certain version'
+    required: false
+  github-token:
+    description: 'The GitHub token used to login and to interact with Docker Github Packages'
+    default: ${{ github.token }}
+    required: false
+  kube-config-base64-data:
+    description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
+    required: false
+runs:
+  using: 'node12'
+  main: 'index.js'

run/README.md

@@ -5,6 +5,63 @@ ___
 
 The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf run`.
 
+## Action in Details
+
+### werf binary setup
+ 
+By default, all actions setup actual werf version for [1.1 alpha channel](https://werf.io/releases.html) (more details about channels, werf release cycle and compatibility promise [here](https://werf.io/installation.html#all-changes-in-werf-go-through-all-stability-channels)). 
+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
+  
+```yaml
+- uses: werf/actions/run@v1.1
+  with:
+    channel: alpha
+```
+  
+Withal, it is not necessary to work within release channels, and the user might specify certain werf version with `version` input.
+
+```yaml
+- uses: werf/actions/run@v1.1
+  with:
+    version: v1.1.23
+```
+
+### kubeconfig setup (*optional*)
+
+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 Project Secrets (e.g. with name `KUBE_CONFIG_BASE64_DATA`).
+ 
+* Pass secret with `kube-config-base64-data` input:
+ 
+  ```yaml
+  - uses: werf/actions/run@v1.1
+    with:
+      kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+  ```
+
+### werf ci-env
+
+This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context.  
+ 
+**Note** that `github-token` is optional in this action, and the input is there in case you need to use a non-default token.
+
+By default, action will use the token provided to your workflow.
+
+## Working with werf options
+
+Any werf option can be defined with environment variables:
+
+```yaml
+- uses: werf/actions/run@v1.1
+  env:
+    WERF_LOG_VERBOSE: "on"
+    WERF_TAG_CUSTOM_TAG1: tag1
+    WERF_TAG_CUSTOM_TAG2: tag2
+```
+
 ## Inputs
 
 ```yaml
@@ -40,12 +97,12 @@ run:
   steps:
   
     - name: Checkout code
-      uses: actions/checkout@v4
+      uses: actions/checkout@v2
       with:
         fetch-depth: 0
 
     - name: Run
-      uses: werf/actions/run@v2
+      uses: werf/actions/run@v1.1
       with:
         image: backend
         args: rails server

run/action.yml

@@ -26,5 +26,5 @@ inputs:
     description: 'Base64 encoded kubeconfig data used for deployment, cleanup and distributed locks'
     required: false
 runs:
-  using: 'node20'
+  using: 'node12'
   main: 'index.js'

src/build-and-publish.ts

@@ -0,0 +1,12 @@
+import * as core from '@actions/core'
+import {PrepareEnvironAndRunWerfCommand} from './common'
+
+async function run(): Promise<void> {
+  try {
+    await PrepareEnvironAndRunWerfCommand(['build-and-publish'])
+  } catch (error) {
+    core.setFailed(error.message)
+  }
+}
+
+run()

src/common.ts

@@ -7,6 +7,8 @@ import {String} from 'typescript-string-operations'
 import {Manager} from './manager'
 import * as werf from './werf'
 
+const minimalWerfVersion = 'v1.1.17'
+
 export async function PrepareEnvironAndRunWerfCommand(
   args: string[]
 ): Promise<void> {
@@ -45,17 +47,13 @@ export async function SetupKubeConfig(
 export function ProcessGitHubContext(): void {
   if (context.eventName === 'pull_request') {
     if (context.payload.pull_request) {
-      // Do nothing if virtual merge variable is already set
-      if (process.env.WERF_VIRTUAL_MERGE) {
-        return
-      }
-
       const baseSha = context.payload.pull_request.base.sha
       const headSha = context.payload.pull_request.head.sha
 
       process.env.WERF_VIRTUAL_MERGE = '1'
       process.env.WERF_VIRTUAL_MERGE_FROM_COMMIT = headSha
       process.env.WERF_VIRTUAL_MERGE_INTO_COMMIT = baseSha
+
       core.exportVariable('WERF_VIRTUAL_MERGE', '1')
       core.exportVariable('WERF_VIRTUAL_MERGE_FROM_COMMIT', headSha)
       core.exportVariable('WERF_VIRTUAL_MERGE_INTO_COMMIT', baseSha)
@@ -65,15 +63,27 @@ export function ProcessGitHubContext(): void {
 
 export function ValidateWerfVersion(version: string): void {
   const ver = semver.coerce(version)
-  if (ver && ver.major === werf.MAJOR) {
+  if (ver) {
+    if (ver.major !== werf.MAJOR || ver.minor !== werf.MINOR) {
+      throw new Error(
+        String.Format(
+          'The arbitrary version ({0}) must be within the MAJOR.MINOR ({1})',
+          version.trim(),
+          werf.MAJOR_MINOR_GROUP
+        )
+      )
+    }
+
+    if (semver.gte(ver, minimalWerfVersion)) {
       return
     }
+  }
 
   throw new Error(
     String.Format(
-      'werf version {0} is not supported: the version must be semver and within the MAJOR ({1})',
+      'werf version {0} is not supported (expected version must be equal or greater than {1})',
       version.trim(),
-      werf.GROUP
+      minimalWerfVersion
     )
   )
 }

src/deploy.ts

@@ -0,0 +1,13 @@
+import * as core from '@actions/core'
+import {PrepareEnvironAndRunWerfCommand} from './common'
+
+async function run(): Promise<void> {
+  try {
+    process.env.WERF_ENV = core.getInput('env')
+    await PrepareEnvironAndRunWerfCommand(['deploy'])
+  } catch (error) {
+    core.setFailed(error.message)
+  }
+}
+
+run()

src/install.ts

@@ -1,11 +1,8 @@
 import * as core from '@actions/core'
 import {Manager} from './manager'
-import {ProcessGitHubContext} from './common'
 
 async function run(): Promise<void> {
   try {
-    ProcessGitHubContext()
-
     const m = new Manager()
     await m.Install()
   } catch (error) {

src/manager.ts

@@ -83,11 +83,6 @@ export class Manager {
     const tmpFilePath = tmpFile.name
     await this.Exec(['ci-env', 'github', '--as-env-file', '-o', tmpFilePath])
     const res = dotenv.config({path: tmpFilePath})
-    if (res.parsed) {
-      for (const [key, value] of Object.entries(res.parsed)) {
-        core.exportVariable(key, value)
-      }
-    }
     console.log(res.parsed)
     tmpFile.removeCallback()
   }
@@ -125,7 +120,7 @@ export class Manager {
       return this._constructReleaseUrl(version)
     }
 
-    const url = `${WERF_TUF_SERVER_URL}/targets/channels/${werf.GROUP}/${this.channel}`
+    const url = `${WERF_TUF_SERVER_URL}/targets/channels/${werf.MAJOR_MINOR_GROUP}/${this.channel}`
     try {
       const resp = await request
         .get(url)

src/publish.ts

@@ -0,0 +1,12 @@
+import * as core from '@actions/core'
+import {PrepareEnvironAndRunWerfCommand} from './common'
+
+async function run(): Promise<void> {
+  try {
+    await PrepareEnvironAndRunWerfCommand(['publish'])
+  } catch (error) {
+    core.setFailed(error.message)
+  }
+}
+
+run()

src/werf.ts

@@ -1,2 +1,3 @@
-export const GROUP = '2'
+export const MAJOR_MINOR_GROUP = '1.1'
-export const MAJOR = 2
+export const MAJOR = 1
+export const MINOR = 1