actions/fluxcd-flux2
3
0
Fork 0
mirror of https://github.com/fluxcd/flux2.git synced 2026-02-22 15:41:47 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

proofreading changes

Browse source 
The menu entry in the Use Cases section was missing, and some of the
text needed additional words to be added in order to make better sense.

Signed-off-by: Kingdon Barrett <kingdon@weave.works>
This commit is contained in:
Kingdon Barrett 2021-04-26 12:42:33 -04:00
parent a5b8840912
commit 85b3eeb87b
No known key found for this signature in database
GPG key ID: 470B0A4ACF2A4E23
2 changed files with 6 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/use-cases/gh-actions-auto-pr.md
View file

@ -2,7 +2,7 @@
In the [Image Update Guide] we saw we can [Push updates to a different branch] by using `.spec.git.push.branch` to push image updates to a different branch than the one used for checkout.
In this example, we configure an `ImageUpdateAutomation` resource to push to a `staging` branch, which we could set up separately as a preview environment to deploy automatic updates in a staging cluster or namespace.
In this example, we configure an `ImageUpdateAutomation` resource to push to a `staging` branch, (which we could set up separately as a preview environment to deploy automatic updates in a staging cluster or namespace.)
```yaml
kind: ImageUpdateAutomation
@ -17,6 +17,8 @@ spec:
branch: staging
```
For this use case, we are only interested in showing that once the change is approved and merged, it gets deployed into production. The image automation is gated behind a pull request approval workflow, according to any policy you have in place for your repository.
In your manifest repository, add a GitHub Action workflow as below. This workflow watches for commits on the `staging` branch and opens a pull request with any labels, title, or body that you configure.
```yaml
@ -45,9 +47,9 @@ jobs:
github_token: ${{ secrets.GITHUB_TOKEN }}
```
You can use the [github-pull-request-action] workflow to automatically open a pull request against a destination branch. In this case, when a pull request is merged into the main changes are deployed in production.
You can use the [github-pull-request-action] workflow to automatically open a pull request against a destination branch. In this case, when `staging` is merged into the `main` branch, changes are deployed in production.
This way you can manually approve automatic image updates before they are applied on your production clusters.
This way you can automatically push changes to a `staging` branch and require manual approval of any automatic image updates before they are applied on your production clusters.
[Image Update Guide]: /guides/image-update/
[Push updates to a different branch]: /guides/image-update/#push-updates-to-a-different-branch

1
mkdocs.yml
View file

@ -67,6 +67,7 @@ nav:
- Use Cases:
- Azure: use-cases/azure.md
- GitHub Actions Manifest Generation: use-cases/gh-actions-manifest-generation.md
- GitHub Actions Auto Pull Request: use-cases/gh-actions-auto-pr.md
- Helm: use-cases/helm.md
- Toolkit Components:
- Overview: components/index.md