diff --git a/README.md b/README.md index 6af463a..5ff41f2 100644 --- a/README.md +++ b/README.md @@ -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. -**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. +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. ## Working with werf options @@ -86,18 +85,39 @@ Any werf option can be defined with environment variables: ## 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/`. + +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 +- 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 env: WERF_REPO: "gcr.io/company/app" 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 @@ -180,6 +200,8 @@ cleanup: 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 }} ``` ### install diff --git a/build/README.md b/build/README.md index 1e79a3d..0428da5 100644 --- a/build/README.md +++ b/build/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 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 ```yaml diff --git a/cleanup/README.md b/cleanup/README.md index 8e222eb..b062126 100644 --- a/cleanup/README.md +++ b/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.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 ```yaml @@ -97,4 +42,6 @@ cleanup: 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 }} ``` diff --git a/converge/README.md b/converge/README.md index e6bb48b..77bcde0 100644 --- a/converge/README.md +++ b/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.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 ```yaml diff --git a/dismiss/README.md b/dismiss/README.md index 331fa60..7e758c5 100644 --- a/dismiss/README.md +++ b/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.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 ```yaml diff --git a/run/README.md b/run/README.md index 8c2b246..670fc5a 100644 --- a/run/README.md +++ b/run/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 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 ```yaml