Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

Thanks for opening an issue! We've triaged this issue for technical review by a subject matter expert 👀

Thanks for the issue @scottdickerson! I'll get this triaged for review.

I think you also need to configure write access for the repository in the settings page of the package. If you had originally published the package from a workflow in the repository this would have been setup automatically iinm. The most up-to-date information that I found is here: https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package

I also summarized my findings here: actions/setup-node#49 (comment)
It would be great if that information could be verified and incorporated into the docs.

Based on our testing, this is what APPEARS to be the case. It would be good if y'all can confirm on your side:

If the package was originally published with a PAT. We cannot publish a new version of the package to our organization repository using the OOTB GITHUB_TOKEN, even if we explicitly set these permissions

permissions:
  packages: write # needed for push of package
  contents: write # needed for push of tags
  pull-requests: read # needed to view the PR for the slack
  repository-projects: read # needed for view the PR for the slack https://github.com/cli/cli/issues/6274

We receive a 403 error.

If we change the publish to use the exact PAT that published the package initially, the new versions can be published.

If we change the PAT to a different persons PAT that did not publish the package initially, we cannot publish any new versions of the package. We get another 403 error.

this new document: is getting REALLY close to telling us this publish package permissions behavior:
https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens
But it is silent on those package permissions, and also doesn't cover initial package creation versus management for an organization package.

Have you looked at the configuration page for your package, @scottdickerson ?
As described in the docs you can configure which pipelines can have access to it (using their GITHUB_TOKEN I assume).

@bodograumann I think this might be getting close to the issue. We just created a new package as part of a npm publish running from a workflow in the skeletor repo (I believe using a PAT for the npm publish). However, the package doesn't seem to have been linked to the repo with any permissions automatically. For my old packages I think we manually added these extra permissions. Is that correct? Should the package be automatically linking the repo when it gets published?

This is what the package settings page looked like after the new package was created:

The first box "Repository source" actually shows that the package has been linked correctly with the repository. (You could remove the link with the trash icon)
No explicit permissions have been defined though. That is what the second box "Manage Actions access" is for.
I thought this was required to publish updates, so I am unsure why it wasn't added automatically.
There is more thing further down though, which says "inherit permissions from linked repository".
So it could also be that when the pipeline is run on the linked repository, it automatically inherits the write permissions from there.

yeah you're even closer I think to the issue, this one is also set false by default for that new repo

AND I see an explicit grant that matches ME which was the PAT used to create the package:

So ideally the new package would inherit access from the repo so that anyones PAT in the repo could publish. However, I still don't know if a GITHUB_TOKEN could really publish a new package initially. Also if we do switch from a PAT back to a GITHUB_TOKEN, does it have the rights to publish a new version of a package that was previously published by a PAT?

This is a gentle bump for the docs team that this issue is waiting for technical review.

This is a gentle bump for the docs team that this issue is waiting for technical review.

PSA

Please also note that even when you correctly configure access to a package from a workflow, you still might get a 403 http error upon accessing the package for some time.

There might be some permission caching going on for the package registry access.
In the case I observed, we are using the github npm registry, self-hosted runners, NODE_AUTH_TOKEN: ${{ github.token }} and tried to rerun a failed workflow after setting up the correct permissions.
As it was late in the evening we gave up and tried again this morning. Now without changing anything else it suddenly works.

This is a gentle bump for the docs team that this issue is waiting for technical review.

This is a gentle bump for the docs team that this issue is waiting for technical review.

👋 from GitHub Docs. I want to extend my appreciation for this conversation, in particular the discussion and insight around the technical issues associated with the product and the willing assistance and support you’ve provided each other here while troubleshooting the problem originally described 💖. However, since this issue has been opened for quite some time and the product has changed a bit over that time period, and given that we don’t have a clear understanding of the exact docs updates required, I’m going to close the issue.

If anyone is continuing to experience the behaviours described in this issue and you’d like to diagnose further, I strongly recommend getting in touch with our Support team and providing as many details as you can about the investigation you’ve already performed and any patterns of behaviour you've observed.

If after discussing the problem with our support team, you can collate, link to, or suggest specific docs updates, then feel free to create a new issue and link it to this one, and then we can review the proposed docs updates. 🙇

Thanks again for your interest and passion in improving the GitHub Docs and supporting the GitHub community along the way 💛 .

Just to add that @bodograumann is exactly right. There is defo some sort of caching on package permissions. Takes a while for GITHUB actions to be able to access new packages.