diff --git a/README.md b/README.md index b1a5009..b2f822e 100644 --- a/README.md +++ b/README.md @@ -1,34 +1,34 @@

- +

___ -This action set allows you to organize CI/CD with GitHub Actions and [werf](https://github.com/flant/werf). The set consists of several independent and complex actions: +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: -- [flant/werf-actions/converge](https://github.com/flant/werf-actions/tree/master/converge) -- [flant/werf-actions/build-and-publish](https://github.com/flant/werf-actions/tree/master/build-and-publish) -- [flant/werf-actions/build](https://github.com/flant/werf-actions/tree/master/build) -- [flant/werf-actions/publish](https://github.com/flant/werf-actions/tree/master/build) -- [flant/werf-actions/deploy](https://github.com/flant/werf-actions/tree/master/deploy) -- [flant/werf-actions/dismiss](https://github.com/flant/werf-actions/tree/master/dismiss) -- [flant/werf-actions/run](https://github.com/flant/werf-actions/tree/master/run) -- [flant/werf-actions/cleanup](https://github.com/flant/werf-actions/tree/master/cleanup) +- [werf/actions/converge](https://github.com/werf/actions/tree/master/converge) +- [werf/actions/build-and-publish](https://github.com/werf/actions/tree/master/build-and-publish) +- [werf/actions/build](https://github.com/werf/actions/tree/master/build) +- [werf/actions/publish](https://github.com/werf/actions/tree/master/build) +- [werf/actions/deploy](https://github.com/werf/actions/tree/master/deploy) +- [werf/actions/dismiss](https://github.com/werf/actions/tree/master/dismiss) +- [werf/actions/run](https://github.com/werf/actions/tree/master/run) +- [werf/actions/cleanup](https://github.com/werf/actions/tree/master/cleanup) Each action combines all the necessary steps in itself and logic may be divided into __environment setup__ and launching the corresponding command. -> Also, there is another action — [flant/werf-actions/install](https://github.com/flant/werf-actions/tree/master/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/master/install). With this action a user can just install werf and use binary within job steps for own purposes ## Environment setup 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: group: 1.1 channel: alpha @@ -37,7 +37,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: version: v1.1.16 ``` @@ -51,7 +51,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/build-and-publish@master + - uses: werf/actions/build-and-publish@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -69,7 +69,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/build-and-publish@master +- uses: werf/actions/build-and-publish@master env: WERF_LOG_VERBOSE: "on" WERF_TAG_CUSTOM_TAG1: tag1 @@ -92,7 +92,7 @@ converge: fetch-depth: 0 - name: Converge - uses: flant/werf-actions/converge@master + uses: werf/actions/converge@master with: env: production kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} @@ -112,7 +112,7 @@ build-and-publish: fetch-depth: 0 - name: Build and Publish - uses: flant/werf-actions/build-and-publish@master + uses: werf/actions/build-and-publish@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} @@ -128,7 +128,7 @@ deploy: fetch-depth: 0 - name: Deploy - uses: flant/werf-actions/deploy@master + uses: werf/actions/deploy@master with: env: production kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} @@ -146,7 +146,7 @@ dismiss: uses: actions/checkout@v2 - name: Dismiss - uses: flant/werf-actions/dismiss@master + uses: werf/actions/dismiss@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} env: production @@ -166,7 +166,7 @@ run: fetch-depth: 0 - name: Run - uses: flant/werf-actions/run@master + uses: werf/actions/run@master with: image: backend args: rails server @@ -190,7 +190,7 @@ cleanup: run: git fetch --prune --unshallow - name: Cleanup - uses: flant/werf-actions/cleanup@master + uses: werf/actions/cleanup@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -207,7 +207,7 @@ werf: uses: actions/checkout@master - name: Install werf CLI - uses: flant/werf-actions/install@master + uses: werf/actions/install@master # for deploy and distributed locks - name: Create kube config diff --git a/build-and-publish/README.md b/build-and-publish/README.md index da31d5c..2701515 100644 --- a/build-and-publish/README.md +++ b/build-and-publish/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/build-and-publish@master +- uses: werf/actions/build-and-publish@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/build-and-publish@master +- uses: werf/actions/build-and-publish@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/build-and-publish@master + - uses: werf/actions/build-and-publish@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/build-and-publish@master +- uses: werf/actions/build-and-publish@master env: WERF_LOG_VERBOSE: "on" WERF_TAG_CUSTOM_TAG1: tag1 @@ -100,7 +100,7 @@ build-and-publish: fetch-depth: 0 - name: Build and Publish - uses: flant/werf-actions/build-and-publish@master + uses: werf/actions/build-and-publish@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` diff --git a/build/README.md b/build/README.md index 0732dee..add5b10 100644 --- a/build/README.md +++ b/build/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/build@master +- uses: werf/actions/build@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/build@master +- uses: werf/actions/build@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/build@master + - uses: werf/actions/build@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/build@master +- uses: werf/actions/build@master env: WERF_LOG_VERBOSE: "on" WERF_TAG_CUSTOM_TAG1: tag1 @@ -100,7 +100,7 @@ build: fetch-depth: 0 - name: Build - uses: flant/werf-actions/build@master + uses: werf/actions/build@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` diff --git a/cleanup/README.md b/cleanup/README.md index aeef69c..fcb1483 100644 --- a/cleanup/README.md +++ b/cleanup/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/cleanup@master +- uses: werf/actions/cleanup@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/cleanup@master +- uses: werf/actions/cleanup@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/cleanup@master + - uses: werf/actions/cleanup@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/cleanup@master +- uses: werf/actions/cleanup@master env: WERF_LOG_VERBOSE: "on" ``` @@ -99,7 +99,7 @@ cleanup: run: git fetch --prune --unshallow - name: Cleanup - uses: flant/werf-actions/cleanup@master + uses: werf/actions/cleanup@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` diff --git a/converge/README.md b/converge/README.md index 1c11ffa..8575794 100644 --- a/converge/README.md +++ b/converge/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/converge@master + - uses: werf/actions/converge@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: env: production env: @@ -103,7 +103,7 @@ converge: fetch-depth: 0 - name: Converge - uses: flant/werf-actions/converge@master + uses: werf/actions/converge@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} env: production diff --git a/deploy/README.md b/deploy/README.md index 578a4c4..3847bd1 100644 --- a/deploy/README.md +++ b/deploy/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/deploy@master +- uses: werf/actions/deploy@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/deploy@master +- uses: werf/actions/deploy@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/deploy@master + - uses: werf/actions/deploy@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/deploy@master +- uses: werf/actions/deploy@master with: env: production env: @@ -103,7 +103,7 @@ deploy: fetch-depth: 0 - name: Deploy - uses: flant/werf-actions/deploy@master + uses: werf/actions/deploy@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} env: production diff --git a/dismiss/README.md b/dismiss/README.md index ea7a861..944b852 100644 --- a/dismiss/README.md +++ b/dismiss/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/converge@master + - uses: werf/actions/converge@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/converge@master +- uses: werf/actions/converge@master with: env: production env: @@ -101,7 +101,7 @@ dismiss: uses: actions/checkout@v2 - name: Dismiss - uses: flant/werf-actions/dismiss@master + uses: werf/actions/dismiss@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} env: production diff --git a/install/README.md b/install/README.md index c05bf64..830a4b9 100644 --- a/install/README.md +++ b/install/README.md @@ -1,15 +1,15 @@

- +

___ -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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/install@master +- uses: werf/actions/install@master with: group: 1.1 channel: alpha @@ -18,7 +18,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/install@master +- uses: werf/actions/install@master with: version: v1.1.16 ``` @@ -51,7 +51,7 @@ werf: uses: actions/checkout@master - name: Install werf CLI - uses: flant/werf-actions/install@master + uses: werf/actions/install@master # for deploy and distributed locks - name: Create kube config diff --git a/package.json b/package.json index b6ad631..2eb2c69 100644 --- a/package.json +++ b/package.json @@ -36,16 +36,15 @@ "pack": "pack.sh", "all": "npm run build && npm run format && npm run lint && npm run pack" }, - "private": true, "repository": { "type": "git", - "url": "git+https://github.com/flant/werf-actions.git" + "url": "git+https://github.com/werf/actions.git" }, "keywords": [], "author": "flant", "license": "Apache License 2.0", "bugs": { - "url": "https://github.com/flant/werf-actions/issues" + "url": "https://github.com/werf/actions/issues" }, - "homepage": "https://github.com/flant/werf-actions#readme" + "homepage": "https://github.com/werf/actions#readme" } diff --git a/publish/README.md b/publish/README.md index 4e1db01..8eedefc 100644 --- a/publish/README.md +++ b/publish/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/publish@master +- uses: werf/actions/publish@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/publish@master +- uses: werf/actions/publish@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/publish@master + - uses: werf/actions/publish@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/publish@master +- uses: werf/actions/publish@master env: WERF_LOG_VERBOSE: "on" WERF_TAG_CUSTOM_TAG1: tag1 @@ -100,7 +100,7 @@ publish: fetch-depth: 0 - name: Publish - uses: flant/werf-actions/publish@master + uses: werf/actions/publish@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` diff --git a/run/README.md b/run/README.md index 7b238c4..6545488 100644 --- a/run/README.md +++ b/run/README.md @@ -1,5 +1,5 @@

- +

___ @@ -9,13 +9,13 @@ The action combines all the necessary steps in itself and logic may be divided i ### 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/flant/werf#backward-compatibility-promise)). +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 `group` and `channel` inputs 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: flant/werf-actions/run@master +- uses: werf/actions/run@master with: group: 1.1 channel: alpha @@ -24,7 +24,7 @@ Using `group` and `channel` inputs 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: flant/werf-actions/run@master +- uses: werf/actions/run@master with: version: v1.1.16 ``` @@ -38,7 +38,7 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach * Pass secret with `kube-config-base64-data` input: ```yaml - - uses: flant/werf-actions/run@master + - uses: werf/actions/run@master with: kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} ``` @@ -56,7 +56,7 @@ By default, action will use the token provided to your workflow. Any werf option can be defined with environment variables: ```yaml -- uses: flant/werf-actions/run@master +- uses: werf/actions/run@master env: WERF_LOG_VERBOSE: "on" WERF_TAG_CUSTOM_TAG1: tag1 @@ -107,7 +107,7 @@ run: fetch-depth: 0 - name: Run - uses: flant/werf-actions/run@master + uses: werf/actions/run@master with: image: backend args: rails server