Merge pull request #54 from werf/chore_readme_fix_links

chore(readme): fix links

.github/workflows/test.yaml

@@ -38,6 +38,6 @@ jobs:
       - name: Install
         uses: ./install
         with:
-          version: v1.1.23+fix50
+          version: v1.2.35
 
       - run: werf version

README.md

@@ -5,44 +5,41 @@ ___
 
 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:
 
-- [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)
+- [werf/actions/converge](https://github.com/werf/actions/tree/v1.2/converge)
+- [werf/actions/dismiss](https://github.com/werf/actions/tree/v1.2/dismiss)
+- [werf/actions/build](https://github.com/werf/actions/tree/v1.2/build)
+- [werf/actions/run](https://github.com/werf/actions/tree/v1.2/run)
+- [werf/actions/cleanup](https://github.com/werf/actions/tree/v1.2/cleanup)
 
-Each action combines all the necessary steps in itself and logic may be divided into environment setup and launching the corresponding command. 
+Each action combines all the necessary steps in itself, and logic may be divided into [environment setup](#environment-setup-in-details) and launching the corresponding command. 
 
-**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).
+**Ready-to-use GitHub Actions Workflows** for different CI/CD workflows are available [here](https://werf.io/documentation/v1.2/advanced/ci_cd/github_actions.html#complete-set-of-configurations-for-ready-made-workflows).
 
-> 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
+> Also, there is another action — [werf/actions/install](https://github.com/werf/actions/tree/v1.2/install). With this action, the user can install werf and use binary within job steps for own purposes.
 
 ## Versioning
 
-When using actions, select the version corresponding to the `MAJOR.MINOR` version of werf:
+When using actions, select the version corresponding to the required `MAJOR.MINOR` version of werf:
 
 ```yaml
-# run converge with actual werf version for 1.1 alpha channel
+# Run converge using actual werf version within 1.1 alpha channel.
 - uses: werf/actions/converge@v1.1
 
-# run converge with actual werf version for 1.2 alpha channel
+# Run converge using actual werf version within 1.2 alpha channel.
 - uses: werf/actions/converge@v1.2
 ```
 
 ## Environment setup in details
 
-### werf binary setup
+### werf binary installation
 
-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)). 
+By default, all actions install actual werf version within 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)). 
 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
+> 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
+- uses: werf/actions/converge@v1.2
   with:
     channel: alpha
 ```
@@ -50,59 +47,79 @@ 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/converge@v1.1
+- uses: werf/actions/converge@v1.2
   with:
-    version: v1.1.23
+    version: v1.2.9
 ```
 
+### werf ci-env
+
+This is the step where an action: 
+
+- sets the defaults for werf command options based on [GitHub Workflow environment variables](https://docs.github.com/en/actions/reference/environment-variables) (e.g. container repository address to the `WERF_REPO` environment variable using the following pattern: `ghcr.io/$GITHUB_REPOSITORY/<project-from-werf.yaml>`).
+- performs _docker login_ to `ghcr.io` using the `github-token` input (only if `ghcr.io` used as `WERF_REPO`).
+
+> The `github-token` input 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](https://docs.github.com/en/actions/reference/authentication-in-a-workflow#about-the-github_token-secret).
+
 ### 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`).
+* Prepare _kubeconfig_ (e.g. `cat ~/.kube/config | base64`) and save in [GitHub Secrets](https://docs.github.com/en/actions/reference/encrypted-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
+  - uses: werf/actions/converge@v1.2
     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:
+All werf options can be defined with environment variables:
 
 ```yaml
-- uses: werf/actions/build-and-publish@v1.1
+- uses: werf/actions/converge@v1.2
   env:
-    WERF_LOG_VERBOSE: "on"
-    WERF_TAG_CUSTOM_TAG1: tag1
-    WERF_TAG_CUSTOM_TAG2: tag2
+    WERF_LOG_VERBOSE: "on" # The same as using the option --log-verbose=on.
 ```
 
 ## Working with container registry
 
-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`).
+### Default container repository
 
-If necessary, the user can define an arbitrary container registry using the `WERF_REPO` and `WERF_REPO_IMPLEMENTATION` environment variables.
+An action generates the default container repository address and performs _docker login_ to the registry within [werf ci-env step](#werf-ci-env).
+
+For cleanup action, the user needs [to create personal access token](https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-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](https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets).
 
 ```yaml
-- uses: werf/actions/converge@v1.1
+- uses: werf/actions/cleanup@v1.2
+  with:
+    kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
   env:
-    WERF_REPO: "gcr.io/company/app"
-    WERF_REPO_IMPLEMENTATION: "gcr"
+    WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_CLEANUP_PAM }}
 ```
 
-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).
+### Custom container repository
+
+An arbitrary container repository can be specified with the `WERF_REPO` and `WERF_REPO_CONTAINER_REGISTRY` environment variables. For instance, steps for GCR:
+
+```yaml
+- name: Login to GCR
+  uses: docker/login-action@v1
+  with:
+    registry: gcr.io
+    username: _json_key
+    password: ${{ secrets.GCR_JSON_KEY }}
+    
+- uses: werf/actions/converge@v1.2
+  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](https://werf.io/documentation/v1.2/advanced/supported_container_registries.html).
 
 ## Examples
 
@@ -120,43 +137,7 @@ converge:
         fetch-depth: 0
 
     - name: Converge
-      uses: werf/actions/converge@v1.1
-      with:
-        env: production
-        kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
-```
-
-### build, publish and deploy
-
-```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 }}
-
-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
+      uses: werf/actions/converge@v1.2
       with:
         env: production
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
@@ -174,7 +155,7 @@ dismiss:
       uses: actions/checkout@v2
 
     - name: Dismiss
-      uses: werf/actions/dismiss@v1.1
+      uses: werf/actions/dismiss@v1.2
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
         env: production
@@ -194,7 +175,7 @@ run:
         fetch-depth: 0
 
     - name: Run
-      uses: werf/actions/run@v1.1
+      uses: werf/actions/run@v1.2
       with:
         image: backend
         args: rails server
@@ -218,9 +199,11 @@ cleanup:
       run: git fetch --prune --unshallow
 
     - name: Cleanup
-      uses: werf/actions/cleanup@v1.1
+      uses: werf/actions/cleanup@v1.2
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+      env:
+        WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_CLEANUP_PAM }}
 ```
 
 ### install
@@ -235,9 +218,9 @@ werf:
       uses: actions/checkout@v2
 
     - name: Install werf CLI  
-      uses: werf/actions/install@v1.1
+      uses: werf/actions/install@v1.2
     
-    # for deploy and distributed locks
+    # For deploy and distributed locks.
     - name: Create kube config
       run: |
         KUBECONFIG=$(mktemp -d)/config
@@ -249,30 +232,13 @@ werf:
     - name: Run werf commands
       run: |
         source $(werf ci-env github --as-file)
-        werf build-and-publish
-        werf deploy
+        werf render
+        werf converge
       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)

build-and-publish/README.md

@@ -1,101 +0,0 @@
-<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

@@ -1,24 +0,0 @@
-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,63 +5,6 @@ ___
 
 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
@@ -95,7 +38,7 @@ build:
         fetch-depth: 0
 
     - name: Build
-      uses: werf/actions/build@v1.1
+      uses: werf/actions/build@v1.2
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
 ```

cleanup/README.md

@@ -5,61 +5,6 @@ ___
 
 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
@@ -94,7 +39,9 @@ cleanup:
       run: git fetch --prune --unshallow
 
     - name: Cleanup
-      uses: werf/actions/cleanup@v1.1
+      uses: werf/actions/cleanup@v1.2
       with:
         kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
+      env:
+        WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_CLEANUP_PAM }}
 ```

converge/README.md

@@ -5,63 +5,6 @@ ___
 
 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
@@ -98,7 +41,7 @@ converge:
         fetch-depth: 0
 
     - name: Converge
-      uses: werf/actions/converge@v1.1
+      uses: werf/actions/converge@v1.2
       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:
+  env: # TODO: Remove this deprecated werf option, which is not required anymore (use WERF_ENV variable instead)
     description: 'Specific deployment environment'
-    required: true
+    required: false
   github-token:
     description: 'The GitHub token used to login and to interact with Docker Github Packages'
     default: ${{ github.token }}

deploy/README.md

@@ -1,105 +0,0 @@
-<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

@@ -1,27 +0,0 @@
-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,63 +5,6 @@ ___
 
 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
@@ -96,7 +39,7 @@ dismiss:
       uses: actions/checkout@v2
 
     - name: Dismiss
-      uses: werf/actions/dismiss@v1.1
+      uses: werf/actions/dismiss@v1.2
       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:
+  env: # TODO: Remove this deprecated werf option, which is not required anymore (use WERF_ENV variable instead)
     description: 'Specific deployment environment'
-    required: true
+    required: false
   github-token:
     description: 'The GitHub token used to login and to interact with Docker Github Packages'
     default: ${{ github.token }}

install/README.md

@@ -3,13 +3,13 @@
 </p>
 ___
  
-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)). 
+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)). 
 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@v1.1
+- uses: werf/actions/install@v1.2
   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@v1.1
+- uses: werf/actions/install@v1.2
   with:
-    version: v1.1.23
+    version: v1.2.9
 ```
 
 ## Inputs
@@ -46,9 +46,9 @@ werf:
       uses: actions/checkout@v2
 
     - name: Install werf CLI  
-      uses: werf/actions/install@v1.1
+      uses: werf/actions/install@v1.2
     
-    # for deploy and distributed locks
+    # For deploy and distributed locks.
     - name: Create kube config
       run: |
         KUBECONFIG=$(mktemp -d)/config
@@ -60,8 +60,8 @@ werf:
     - name: Run werf commands
       run: |
         source $(werf ci-env github --as-file)
-        werf build-and-publish
-        werf deploy
+        werf render
+        werf converge
       env:
         GITHUB_TOKEN: ${{ github.token }}
         WERF_ENV: production

install/action.yml

@@ -1,6 +1,6 @@
 name: Install werf CLI
 author: 'Flant'
-description: 'Install actual channel werf version, like multiwerf does, or specified one'
+description: 'Install werf CLI'
 branding:
   color: blue
   icon: anchor

pack.sh

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

package.json

@@ -1,6 +1,6 @@
 {
   "name": "werf-actions",
-  "version": "1.1.1",
+  "version": "1.2.1",
   "description": "",
   "main": "lib",
   "dependencies": {
@@ -25,7 +25,7 @@
     "eslint": "^7.32.0",
     "eslint-plugin-github": "^4.3.2",
     "js-yaml": "^3.13.1",
-    "node-fetch": ">=2.6.1",
+    "node-fetch": ">=3.1.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

@@ -1,101 +0,0 @@
-<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

@@ -1,24 +0,0 @@
-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,63 +5,6 @@ ___
 
 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
@@ -102,7 +45,7 @@ run:
         fetch-depth: 0
 
     - name: Run
-      uses: werf/actions/run@v1.1
+      uses: werf/actions/run@v1.2
       with:
         image: backend
         args: rails server

src/build-and-publish.ts

@@ -1,12 +0,0 @@
-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/deploy.ts

@@ -1,13 +0,0 @@
-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/publish.ts

@@ -1,12 +0,0 @@
-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,3 +1,3 @@
-export const MAJOR_MINOR_GROUP = '1.1'
+export const MAJOR_MINOR_GROUP = '1.2'
 export const MAJOR = 1
-export const MINOR = 1
+export const MINOR = 2