chore: fix typo (#2316)

This commit is contained in:
Jerry Jones 2022-11-10 12:35:15 -05:00 committed by GitHub
parent ce00d2cd63
commit cf9a334cb0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 5 additions and 5 deletions

View File

@ -563,7 +563,7 @@ docker run -ti --rm -e GOOGLE_APPLICATION_CREDENTIALS=/kaniko/config.json \
#### Pushing to GCR using Workload Identity
If you have enabled Workload Indentity on your GKE cluster then you can use the
If you have enabled Workload Identity on your GKE cluster then you can use the
workload identity to push built images to GCR without adding a
`GOOGLE_APPLICATION_CREDENTIALS` in your kaniko pod specification.
@ -1004,7 +1004,7 @@ multiple times for multiple registries.
#### Flag `--skip-unused-stages`
This flag builds only used stages if defined to `true`. Otherwise it builds by
default all stages, even the unnecessaries ones until it reaches the target
default all stages, even the unnecessary ones until it reaches the target
stage / end of Dockerfile
#### Flag `--snapshotMode`
@ -1124,7 +1124,7 @@ profiling,
1. Add an environment variable `STACKLOG_PATH` to your
[pod definition](https://github.com/GoogleContainerTools/kaniko/blob/master/examples/pod-build-profile.yaml#L15).
2. If you are using the kaniko `debug` image, you can copy the file in the
`pre-stop` container lifecyle hook.
`pre-stop` container lifecycle hook.
## Comparison with Other Tools

View File

@ -37,7 +37,7 @@ Please change all usages of `gcr.io/kaniko-project/executor:latest` to `gcr.io/Y
### Getting write access to the Kaniko Project
In order to kick off kaniko release, you need to write access to Kaniko project.
To get write access, please ping one of the [Kaniko Mantainers](https://github.com/orgs/GoogleContainerTools/teams/kaniko-maintainers/members).
To get write access, please ping one of the [Kaniko Maintainers](https://github.com/orgs/GoogleContainerTools/teams/kaniko-maintainers/members).
Once you have the correct access, you can kick off a release.
@ -94,7 +94,7 @@ You could verify if the images are published using the `docker pull` command
```
docker pull gcr.io/kaniko-project/executor:warmer-vX.Y.Z
```
In case the images are still not published, ping one of the kaniko manintainers and they will provide the cloud build trigger logs.
In case the images are still not published, ping one of the kaniko maintainers and they will provide the cloud build trigger logs.
You can also request read access to the Google `kaniko-project`.
4. Finally, once the images are published, create a release for the newly created [tag](https://github.com/GoogleContainerTools/kaniko/tags) and publish it.