public-mirrors/werf-actions
2
0
Fork 0
mirror of https://github.com/werf/actions.git synced 2026-02-05 02:46:23 +03:00
Code Issues Packages Projects Releases Wiki Activity

[readme] @v1 -> @master

Browse Source
This commit is contained in:
Alexey Igrychev
2020-05-28 07:18:25 +01:00
parent 9dcc6e256f
commit 448f6c68d8
7 changed files with 37 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
README.md
View File

@@ -25,7 +25,7 @@ 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@v1
- uses: flant/werf-actions/converge@master
with:
group: 1.1
channel: alpha
@@ -34,7 +34,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@v1
- uses: flant/werf-actions/converge@master
with:
version: v1.1.16
```
@@ -48,7 +48,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@v1
- uses: flant/werf-actions/build-and-publish@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
```
@@ -66,7 +66,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@v1
- uses: flant/werf-actions/build-and-publish@master
env:
WERF_LOG_VERBOSE: "on"
WERF_TAG_CUSTOM_TAG1: tag1
@@ -143,7 +143,7 @@ dismiss:
uses: actions/checkout@v2
- name: Dismiss
uses: flant/werf-actions/dismiss@v1
uses: flant/werf-actions/dismiss@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env: production
@@ -164,7 +164,7 @@ cleanup:
run: git fetch --prune --unshallow
- name: Cleanup
uses: flant/werf-actions/cleanup@v1
uses: flant/werf-actions/cleanup@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
```
@@ -178,10 +178,10 @@ werf:
steps:
- name: Checkout code
uses: actions/checkout@v1
uses: actions/checkout@master
- name: Install werf CLI
uses: flant/werf-actions/install@v1
uses: flant/werf-actions/install@master
# for deploy and distributed locks
- name: Create kube config

10
build-and-publish/README.md
View File

@@ -15,7 +15,7 @@ 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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
uses: flant/werf-actions/build-and-publish@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
```

10
cleanup/README.md
View File

@@ -15,7 +15,7 @@ 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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
uses: flant/werf-actions/cleanup@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
```

10
converge/README.md
View File

@@ -15,7 +15,7 @@ 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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/werf-actions/converge@master
with:
env: production
env:
@@ -103,7 +103,7 @@ converge:
fetch-depth: 0
- name: Converge
uses: flant/werf-actions/converge@v1
uses: flant/werf-actions/converge@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env: production

10
deploy/README.md
View File

@@ -15,7 +15,7 @@ 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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/werf-actions/deploy@master
with:
env: production
env:
@@ -103,7 +103,7 @@ deploy:
fetch-depth: 0
- name: Deploy
uses: flant/werf-actions/deploy@v1
uses: flant/werf-actions/deploy@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env: production

10
dismiss/README.md
View File

@@ -15,7 +15,7 @@ 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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/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@v1
- uses: flant/werf-actions/converge@master
with:
env: production
env:
@@ -101,7 +101,7 @@ dismiss:
uses: actions/checkout@v2
- name: Dismiss
uses: flant/werf-actions/dismiss@v1
uses: flant/werf-actions/dismiss@master
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env: production

8
install/README.md
View File

@@ -9,7 +9,7 @@ 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@v1
- uses: flant/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@v1
- uses: flant/werf-actions/install@master
with:
version: v1.1.16
```
@@ -48,10 +48,10 @@ werf:
steps:
- name: Checkout code
uses: actions/checkout@v1
uses: actions/checkout@master
- name: Install werf CLI
uses: flant/werf-actions/install@v1
uses: flant/werf-actions/install@master
# for deploy and distributed locks
- name: Create kube config