Add useful info to "pushing a container"#22007
Conversation
When you push a container to ghcr.io without having the label `org.opencontainers.image.source` set GitHub won't connect the image to a repository. This results in the `GITHUB_TOKEN` not having the appropriate permissions. Example: Repository url: `flopana/awesomeRepo` I push an image that is tagged with `ghcr.io/flopana/awesomeRepo:latest` to ghcr.io, GitHub won't link these two together. If I now use the `secrets.GITHUB_TOKEN` in GitHub Actions on the repository `flopana/awesomeRepo` and try to push a container with it it fails with `403 Forbidden`. Because the token belonging to this repository doesn't have the permission to write to a package that is not belonging to this repository. If there is no package under that namespace and you push an image from the pipeline with the github token to ghcr.io, Github will link these two even without the label set. But by advising the user to set the label in the Dockerfile github will link both together regardless of the order of pushing images. My changes in the Documentation should prevent users from running into this problem like I did. Feel free to make changes to my grammar/wording since English isn't my mother tongue.
|
Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines. |
Automatically generated comment ℹ️This comment is automatically generated and will be overwritten every time changes are committed to this branch. The table contains an overview of files in the Content directory changesYou may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.
fpt: Free, Pro, Team |
what? |
|
@flopana Thanks so much for opening a PR! I'll get this triaged for review ⚡ |
|
Thanks for opening a pull request! We've triaged this issue for technical review by a subject matter expert 👀 |
This comment was marked as spam.
This comment was marked as spam.
|
This is a gentle bump for the docs team that this PR is waiting for technical review. |
|
This is a gentle bump for the docs team that this PR is waiting for technical review. |
|
This is a gentle bump for the docs team that this PR is waiting for technical review. |
|
This is a gentle bump for the docs team that this PR is waiting for technical review. |
|
👋 @flopana thanks for your PR and I apologize that it took this long for us to get back on this 💖 . I've spoken with the engineering team and consequently we'd like to add a bit more detail to doc in relation to the issue you're addressing. I'll push a few changes, check on preview, and then merge if all looks good! ⚡ |
|
Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡ |
When you push a container to ghcr.io without having the label
org.opencontainers.image.sourceset GitHub won't connect the image to a repository. This results in theGITHUB_TOKENnot having the appropriate permissions.Example:
Repository url:
flopana/awesomeRepoI push an image that is tagged with
ghcr.io/flopana/awesomeRepo:latestto ghcr.io, GitHub won't link these two together.If I now use the
secrets.GITHUB_TOKENin GitHub Actions on the repositoryflopana/awesomeRepoand try to push a container with it it fails with403 Forbidden. Because the token belonging to this repository doesn't have the permission to write to a package that is not belonging to this repository.If there is no package under that namespace and you push an image from the pipeline with the github token to ghcr.io, Github will link these two even without the label set.
But by advising the user to set the label in the Dockerfile github will link both together regardless of the order of pushing images.
My changes in the Documentation should prevent users from running into this problem like I did.
Feel free to make changes to my grammar/wording since English isn't my mother tongue.
Why:
Should be prevent users from running into permission errors like I did
What's being changed (if available, include any code snippets, screenshots, or gifs):
Stated above, I didn't see this template while writing the text above
Check off the following: