Bug: Compose auth.json always being written to with GITHUB_TOKEN causing issues with Enterprise GitHub workflows

[Sn0wCrack]

Describe the bug

With a recent update, the auth.json file for Composer is always written to using the GITHUB_TOKEN environment.

This is fantastic for running workflows against public GitHub to reduce running into rate limits or other issues, however in Enterprise scenarios this GITHUB_TOKEN only provides access to the Enterprise the runner is attached to, not to the publicly available GitHub.

This causes authentication issues with GitHub on these runners and leads to composer falling back to cloning the repository in each case rather than downloading the release ZIP file.

My current workaround is I have created an empty auth.json file containing {} as its contents and then marked the file as immutable to prevent it being overwritten by this action.

Solutions for this would be:

• By default do not write auth.json for Enterprise. Perhaps adding another running type called enterprise that inherits the self-hosted properties plus a few extra things such as this.
• Allow using COMPOSER_TOKEN to overwrite GITHUB_TOKEN to allow setting a permanent PAT in the self hosted GitHub Action Runner's .env file.

To add to the second point, I see at points during the codebase that GITHUB_TOKEN has a fallback to COMPOSER_TOKEN, however, GITHUB_TOKEN is always set during an action, so there is never a condition COMPOSER_TOKEN is used.

Version

• v2
• v1

Runners

Self Hosted

Operating systems

Ubuntu 24.04

PHP versions

PHP 8.2, 8.4

To Reproduce

Requires a GitHub Enterprise setup to test, this will happen on essentially any stock standard self-hosted runner.

Expected behavior

Writing to auth.json can be disabled or somehow globally overwritten.

Screenshots/Logs

No response

Additional context

No response

Are you willing to submit a PR?

Yes

[shivammathur]

@Sn0wCrack
Does it work correctly if you set the PAT using the new github-token input?

That would set the PAT as the GITHUB_TOKEN env and add that to composer as well for GitHub authentication.

[Sn0wCrack]

That does work, as it internally overwrites the GITHUB_TOKEN environment variable.

It isn't a fully ideal solution as I have quite a number of workflows I'd need to update with this and add in a secret for a PAT.

If the COMPOSER_TOKEN could overwrite the usage of the GITHUB_TOKEN I can set this in a self hosted runner's .env file, meaning I'd only need to push this value to a few servers.

[shivammathur]

@Sn0wCrack

Added the workaround in dcec1cf

Please check if develop works for you, I can do a release later this week.

[Sn0wCrack]

That does indeed work for my scenario and would work well for others who want to use a custom PAT without affecting the GITHUB_TOKEN variable in my opinion.

One thing is it technically doesn't really fully solve the problem that GITHUB_TOKEN is just never going to be correct for GitHub enterprise users for this scenario and not writing the auth.json file automatically in this scenario might be more preferable.

[shivammathur]

@Sn0wCrack

I'm not too familiar with enterprise, would try to get an instance to test it.

Might be a good idea to detect the environment and handle it differently. I have a question though, Wouldn't actions like actions/checkout that have the same configurations for the token input face the same issue, What kind of token would one use for that in enterprise?

[Sn0wCrack]

Happy to assist with testing in that regard.

As for existing actions, most of GitHub's provided ones use the base URL of the instance that the runner is associated to to call APIs, etc. There's no need for them to talk to the public GitHub given they are acting on an enterprise instance.

In terms of the checkout action, if you're cloning a repository from your enterprise instance, it will just work as expected, as the token generated is for your enterprise instance. This is the 99% use case for this action in both public and enterprise in that you don't need to provide a token to have it just work.

In some cases you still need to deal with permissions and such so you'll need to generate a PAT of your own or use a GitHub App and provide the action that PAT. However this PAT is still just for the enterprise instance.

If you are cloning from a public repository that is on github.com on an enterprise GitHub, you need to specify the repository URL, however since its public you don't need to provide a PAT unless you're hitting rate limits.

If you are cloning from a private repository that is on github.com on an enterprise GitHub, you need to specify the repository URL and a PAT for github.com that has access to that repository.

In all cases you need to provide a PAT, it is generally permission related, regardless of public or enterprise GitHub being the target of the action.

[shivammathur]

I'm thinking the following.

On enterprise, we can check the token if it can authenticate with the public GitHub API, if yes (in case user provides a PAT), then write it to auth.json, otherwise no.

I have implemented this in 89b2566. Please do a test with develop and let me know if this works.

[Sn0wCrack]

The changes here look really good! Thanks for taking a look into this.

Once I'm back in the office I'll give this a go, but just looking at it, I imagine this should resolve the issue going forward.

[Sn0wCrack]

Sorry for the delay on this.

I've given this a test today and seems to be working well, my auth.json is no longer being overwritten.