public_git
/
kaniko
mirror of https://github.com/GoogleContainerTools/kaniko
1
0
Fork 0
Code Issues Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -563,7 +563,7 @@ docker run -ti --rm -e GOOGLE_APPLICATION_CREDENTIALS=/kaniko/config.json \
#### Pushing to GCR using Workload Identity #### 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 workload identity to push built images to GCR without adding a
`GOOGLE_APPLICATION_CREDENTIALS` in your kaniko pod specification. `GOOGLE_APPLICATION_CREDENTIALS` in your kaniko pod specification.
@ -1004,7 +1004,7 @@ multiple times for multiple registries.
#### Flag `--skip-unused-stages` #### Flag `--skip-unused-stages`
This flag builds only used stages if defined to `true`. Otherwise it builds by 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 stage / end of Dockerfile
#### Flag `--snapshotMode` #### Flag `--snapshotMode`
@ -1124,7 +1124,7 @@ profiling,
1. Add an environment variable `STACKLOG_PATH` to your 1. Add an environment variable `STACKLOG_PATH` to your
[pod definition](https://github.com/GoogleContainerTools/kaniko/blob/master/examples/pod-build-profile.yaml#L15). [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 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 ## Comparison with Other Tools

4
RELEASE.md
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 ### Getting write access to the Kaniko Project
In order to kick off kaniko release, you need to write access to 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. 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 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`. 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. 4. Finally, once the images are published, create a release for the newly created [tag](https://github.com/GoogleContainerTools/kaniko/tags) and publish it.