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

chore(readme): update according to the latest versions

Browse Source
This commit is contained in:
Alexey Igrychev
2021-08-06 15:19:17 +02:00
parent 2b23b0c4ff
commit b7ed64f2df
6 changed files with 30 additions and 285 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
README.md
View File

@@ -70,9 +70,8 @@ The _kubeconfig_ may be used for deployment, cleanup, distributed locks and cach
This command performs _docker login_ using `github-token`, sets up predefined variables based on GitHub Workflow context. 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. 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.
By default, action will use the token provided to your workflow.
## Working with werf options ## Working with werf options
@@ -86,18 +85,39 @@ Any werf option can be defined with environment variables:
## Working with container registry ## 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_CONTAINER_REGISTRY` environment variables. By default, each action performs authorization and generates container repository address in the following format: `ghcr.io/$GITHUB_REPOSITORY/<project-from-werf.yaml>`.
For cleanup action you need [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. 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 ```yaml
- uses: werf/actions/cleanup@v1.2
with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env:
WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_REPO_GITHUB_TOKEN }}
```
### Custom container repository
The user can use an arbitrary container repository specifying the `WERF_REPO` and `WERF_REPO_CONTAINER_REGISTRY` environment variables and perform authorization yourself. 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 - uses: werf/actions/converge@v1.2
env: env:
WERF_REPO: "gcr.io/company/app" WERF_REPO: "gcr.io/company/app"
WERF_REPO_CONTAINER_REGISTRY: "gcr" WERF_REPO_CONTAINER_REGISTRY: "gcr"
``` ```
To learn how to work with the different container registries, see the corresponding [article in the werf documentation](https://werf.io/v1.2-alpha/documentation/advanced/supported_container_registries.html). > To learn more about how to work with the different container registries, see the appropriate [article in the werf documentation](https://werf.io/v1.2-alpha/documentation/advanced/supported_container_registries.html)
## Examples ## Examples
@@ -180,6 +200,8 @@ cleanup:
uses: werf/actions/cleanup@v1.2 uses: werf/actions/cleanup@v1.2
with: with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env:
WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_REPO_GITHUB_TOKEN }}
``` ```
### install ### install

55
build/README.md
View File

@@ -5,61 +5,6 @@ ___
The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf build`. 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.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/build@v1.2
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.2
with:
version: v1.2.9
```
### 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.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:
```yaml
- uses: werf/actions/build@v1.2
env:
WERF_LOG_VERBOSE: "on"
```
## Inputs ## Inputs
```yaml ```yaml

57
cleanup/README.md
View File

@@ -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`. 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.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/cleanup@v1.2
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.2
with:
version: v1.2.9
```
### 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.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:
```yaml
- uses: werf/actions/cleanup@v1.2
env:
WERF_LOG_VERBOSE: "on"
```
## Inputs ## Inputs
```yaml ```yaml
@@ -97,4 +42,6 @@ cleanup:
uses: werf/actions/cleanup@v1.2 uses: werf/actions/cleanup@v1.2
with: with:
kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }} kube-config-base64-data: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
env:
WERF_REPO_GITHUB_TOKEN: ${{ secrets.WERF_REPO_GITHUB_TOKEN }}
``` ```

57
converge/README.md
View File

@@ -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`. 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.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/converge@v1.2
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.2
with:
version: v1.2.9
```
### 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.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:
```yaml
- uses: werf/actions/converge@v1.2
with:
env: production
env:
WERF_LOG_VERBOSE: "on"
```
## Inputs ## Inputs
```yaml ```yaml

57
dismiss/README.md
View File

@@ -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`. 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.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/converge@v1.2
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.2
with:
version: v1.2.9
```
### 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.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:
```yaml
- uses: werf/actions/converge@v1.2
with:
env: production
env:
WERF_LOG_VERBOSE: "on"
```
## Inputs ## Inputs
```yaml ```yaml

55
run/README.md
View File

@@ -5,61 +5,6 @@ ___
The action combines all the necessary steps in itself and logic may be divided into environment setup and launching `werf run`. 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.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/run@v1.2
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.2
with:
version: v1.2.9
```
### 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.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:
```yaml
- uses: werf/actions/run@v1.2
env:
WERF_LOG_VERBOSE: "on"
```
## Inputs ## Inputs
```yaml ```yaml