Workflow on fork cannot pull packages from organization feed

I’m having a lot of trouble with this.

Enterprise customer, we have an organization (call it “orgy”) and a repo “systems”, owned by that organization, it is private, all developers have a fork of this, of course all forks are private.

I’ve had some success over the past few weeks with GitHub actions and this has mostly gone well.

Workflow triggering for forks is active and seems to work, this initially enabled at the enterprise level as explained in some of the docs.

However the organization has packages and workflows that run on the main repo seem to have no trouble pulling packages from this private package source.

But workflows that are triggered and run on developer forks repeatedly claim the packages can’t be found, we leverage the GITHUB_TOKEN in the workflows.

A developer sitting at home running builds locally can pull the packages, these developers of course have a per-person created PAT.

But why would a workflow running on a fork not be able to at least have read access to the packages in the main organization?

I’ve read a lot of posts around here that talk about “can’t access packages in another repo” but that is not logical, packages are not owned by a repo, they are per-organization, not tied to any repository at all.

We don’t have packages for a reop only for the organization which of course has numerous repos.

Is the GITHUB_TOKEN that’s seen in the workflow running on the fork, actually describing permissions for the user that has the fork? I can see that “I” - the user- have my own packages feed so is it perhaps the case that the GITHUB_TOKEN is not in any way referring to permissions in the main repo (that my fork came from)?

I’d expect that a workflow running on a fork to be given a GITHUB_TOKEN that pertains the organization’s packages who owns the repo from which they forked, not the user’s packages who has the fork.

This article though seems to say that it is done this way:

For forks, the GITHUB_TOKEN is granted read access for the parent repository.

Does that mean read access also to the packages in the organization that owns the parent repository?..

Any assistance is much appreciated.

These users seem to have posted about this area before so I’m mentioning them:

@shayneburgess

PS: I want to also just mention that the actual messages logged for the restore steps in these workflows refers to Unable to find package <whatever> and Unable to find version <whatever> of package <whatever> but scouring the web seems to indicate we can get this message if the package truly does not exist or if access to the source is denied, being unclear about which is a huge pain.

In my case the specific versions of these packages do exist and if the workflows execute in the organization’s repo (as opposed to a fork) these same packages are pulled without issue and the builds work fine.

The error do clearly state the URL of the packages and I can see it is the organization its looking at.

UPDATE UPDATE UPDATE

OK I experimented and explicitly supplied an invalid password to the package source, now I get authorization errors NOT “can’t find package” errors. This now actually seems to be a genuine inability to find the packages.

The same workflows run fine and restore fine when executed in the context of the organization’s repo but always report “can’t find package” when run in the context of a fork of the organization’s repo.

Perhaps the permissions of the GITHUB_TOKEN are insufficient despite the token being valid and authenticating OK.

But everything I’ve read says that the GITHUB_TOKEN passed to the workflow in this situation, defaults to read access to the organization.

This is just beyond confusing, absolutely ridiculously time consuming and fruitless…