Not using "token" on github server

[ecs-jnguyen]

Describe the bug

Hi I am using actions/setup-python on a private github server. When I run curl https://api.github.com/rate_limit in the self-hosted runner I have 60 remaining resources. When I run the curl command again after uses: actions/setup-python I see that the resource counter goes down to 58. Since I am running this action a lot I eventually exceed my api call limit.

I tried using the key token under the with section with a token I created from github cloud but that did not work. I saw that when we are running on github server we are setting the AUTH variable to undefined. Link to code.

I know we are using ${{ github.token }} by default from the actions.yml file. So I believe the check for github server was added so that tokens from the private github server don't get sent to github cloud. Could we add a second input for the token so that people running on private github servers don't run into the api call limit error? Or if we detect that we are running on a private github server, could we try to use actions/python-versions on the github server instead?

Which version of the action are you using?

• v1
• v2
• Some other tag (such as v2.0.1 or master)

Environment

• [ x ] self-hosted
• Linux
• Windows
• Mac

If applicable, please specify if you're using a container

Python Versions

• 3.8
• 3.9

To Reproduce
Steps to reproduce the behavior:

1. Run github actions with actions/setup-python@v2 on github server a lot
2. Then we run into Error: API rate limit exceeded for <IP address>. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

github actions yaml file:

name: CI

on:
  push:
    branches: [ master ]

jobs:
  sample_build:
    runs-on: [ self-hosted ]
    steps:
      - name: "rate limit"
        run: |
          curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/rate_limit

      - name: Set up Python 3.9
        uses: actions/setup-python@v2
        with:
          token: ${{ secrets.GH_CLOUD_TOKEN }}
          python-version: 3.9

      - name: "rate limit"
        run: |
          curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/rate_limit

[brcrista]

When people are hitting the rate limit, is it from a single self-hosted runner being reused for multiple jobs that call actions/setup-python? Or is it possible that multiple self-hosted runners are interacting with each other?

The action will look for a previously installed version of Python before fetching the manifest file (line 50 of the same file). Given that the rate limit is 60/hr for unauthenticated requests, that seems like a lot of different versions for one runner.

If it is one runner, I think the right fix is just to cache the manifest file (which changes relatively infrequently) with an expiry of 1 hour rather than fetching it every time.

[ecs-jnguyen]

In my case, I am running from multiple self-hosted runners. However they are behind a NAT in AWS. This is resulting in their source IP address being the same.

[brcrista]

Thanks, makes sense. Caching the manifest file won't work then.

GitHub Connect is the preferred mechanism for linking GHES to github.com. However, it seems clear to me that we won't have time to do that any time soon.

So I think the best approach is just to remove the nulling-out of the token input for GHES. The description already states that it's for fetching the manifest file, but we should update that to make it clear that the token is always for github.com.

[brcrista]

Reopening; unfortunately we found a flaw in the approach #437

[ecs-jnguyen]

Thanks for keeping me updated.

Do you think we could add a second input parameter that can be used for GHES to pass in the github.com token?

[brcrista]

That's one way to do it, but having separate token and ghes-token inputs means one is just going to no-op depending on your endpoint. Actions such as setup-node would have to do the same thing.

It's clear that there's a feature gap in the @actions/core package -- we're not able to tell whether an input is coming from a default value or if it was passed in. If we had that information, we could check if (isGhes() && !isDefault), use the token in that case, and continue not to send it otherwise.

cc @thboop

[brcrista]

Ok, this should be fixed now in main. If you don't want to wait for the next version update, you can use actions/setup-python@98c991d actions/setup-python@98c991d13f3149457a7c1ac4083885d0d9db98e1.

[kasuteru]

@brcrista what do you mean by fixed? Our organisation is running into the same problem - multiple runners behind the same IP requesting this and getting the rate limit error. How do I fix this?

[brcrista]

@kasuteru can you confirm that you're:

1. using a version of the action with the fix
2. Passing a PAT for github.com (not the GHES instance) as the token input?

[kasuteru]

@brcrista I am using action v4, which is the newest one and should include the fix I think.

But there is a lot of information missing regarding what exactly is needed by this action:

1. What rights does the PAT need? Does it need any at all, or is it enough to create one that has no rights but still identifies me as being me?
2. Is there any way to verify that authentication worked? Currently, this is hard to test because I need to manually overload the API to see whether I succeeded in authenticating or not... I'm never really sure whether I succeeded because I managed to authenticate, or just because the rate limit reset...
3. Is there a way to see whether the action even made a request, or was using cache? Again, hard to debug if I don't know whether a request was even made or not. All I can see is the following:

My code is now as follows:

  - name: Set up Python
    uses: actions/setup-python@v4
    with:
      python-version: 3.8
      token: ${{ secrets.GH_GITHUB_COM_PAT }}

Thanks!

[kasuteru]

Update: I realized I can turn on verbosity by setting a secret. Will evaluate further.

[brcrista]

@kasuteru v4 doesn't have it yet.

(The PR with the fix was merged on Aug 30, but the latest release, v4.2.0, was released on Aug 2. @marko-zivic-93, could you see about getting a new version released with this fix?)

So, you'll have to pull the latest main onto your GHES instance from github.com and use that (actions/setup-python@98c991d actions/setup-python@98c991d13f3149457a7c1ac4083885d0d9db98e1).

What rights does the PAT need?

None; you're just making the call as an authenticated user instead of an anonymous user.

Is there any way to verify that authentication worked?

There's a rate limit API. This YAML snippet has an example.

Is there a way to see whether the action even made a request, or was using cache?

You should see some logging if it has to make the request.

[kasuteru]

Thank you for the reply. I didn't realize v4 didn't have it yet - that explains it.

With your help, I was able to verify that caching indeed usually works, but not always, and when it doesn't work, it almost always runs into the rate limit. I suspect this is because our company has a lot of runners hidden behind the same IP.

When trying to use your version, the following error came up - looks like one needs to always specify the full version.

After specifying the full hash, I was able to confirm that it now works! Thank you!

I will write a separate post-mortem post for anyone stumbling upon this at a later time.

[brcrista]

Thanks! I've updated my previous comments with the full SHA.

I will write a separate post-mortem post for anyone stumbling upon this at a later time.

If you'd like to add anything that tripped you up to our docs for GHES, that would be very helpful!

[kasuteru]

Okay, I'll write a PR with a bit more information on how to tackle this.