pulumi-eks icon indicating copy to clipboard operation
pulumi-eks copied to clipboard

Github action for up/preview/refresh... fails with 401 could not find latest version for provider eks

Open gio-pcb opened this issue 1 year ago • 6 comments
trafficstars

What happened?

I am using pulumi/eks as part of my infra deployment.

When running a pulumi stack action from gh (selfhosted) always fails with error 401.

      - name: Pulumi up
        if: ${{ github.event.inputs.pulumi_action == 'up' }}
        uses: pulumi/actions@v4
        env:
          PULUMI_CONFIG_PASSPHRASE: ${{ secrets.PULUMI_DEV_CONFIG_PASSPHRASE }}
        with:
          work-dir: infra
          cloud-url: s3://xxx
          stack-name: infra
          command: up
          github-token: ${{ secrets.GITHUB_TOKEN }}

I can workaround this by adding a previous step to the workflow as follows:

      - name: Pulumi plugin install
        run: pulumi plugin install resource eks v1.0.4
        working-directory: src/infra
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Example

  Diagnostics:
    pulumi:providers:eks (default):
      error: could not find latest version for provider eks: 401 HTTP error fetching plugin from https://api.github.com/repos/pulumi/pulumi-eks/releases/latest

Output of pulumi about

v3.111.1

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

gio-pcb avatar Apr 15 '24 13:04 gio-pcb

I suspect that GitHub token your setting doesn't have permissions to access the eks repo. When you specify the version to download it can fallback to get.pulumi.com, so the fact the install command works with that token set doesn't really mean that tokens valid.

I did think about changing the engine to disable any set GITHUB_TOKEN when doing downloads if we saw a 401 error come back from using the one set by the user. That would probably have fixed this case, but kinda masks the issue that your token isn't good.

Also your program should be telling the engine what version to use generally, so it doesn't need to do a latest version lookup. That does vary from language to language and you haven't put what language your program is written in here?

Frassle avatar Apr 15 '24 14:04 Frassle

The Github token is only there to avoid the rate limit error that I've experienced in the past, if I remove the token env the action will still complete successfully (with the workaround in place).

My project is in typescript and I am indeed indicating "@pulumi/eks": "^1.0.4" in the package.json

gio-pcb avatar Apr 15 '24 14:04 gio-pcb

Thanks I think this is two issues.

  1. That token for whatever reason isn't actually valid and is getting auth errors back from the GitHub API.
  2. The typescript SDK for eks isn't setting the provider version when it should be.

I don't think there's really anything we can do for issue 1, and issue 2 is a problem in eks so I'm going to move this issue to that repo.

Frassle avatar Apr 15 '24 14:04 Frassle

@Frassle AFAICT this error is unrelated to the SDK's versioning as it's just trying to parse the version from the GitHub release. The tag name is there as expected:

❯ curl -s https://api.github.com/repos/pulumi/pulumi-eks/releases/latest | jq .tag_name
"v2.3.0"

This all seems to be working normally to me -- what else do you need from the EKS side?

When you specify the version to download it can fallback to get.pulumi.com, so the fact the install command works with that token set doesn't really mean that tokens valid.

I agree the token is most likely invalid in this case. It seems like the fallback behavior kicked in for the install but not the up.

blampe avatar Apr 15 '24 16:04 blampe

AFAICT this error is unrelated to the SDK's versioning as it's just trying to parse the version from the GitHub release.

Nope the issue looks to be that the SDK isn't sending a version at runtime. Thus why the user is seeing a diff for pulumi:providers:eks (default) rather than something like pulumi:providers:eks (default_1_0_4).

Something in the SDK is trying to do a custom resource or remote component resource registration and not setting ResourceOptions.Version in that request. The engine is then falling back to its standard logic of "no version given, go look up the latest version and use that".

Now we could probably update that logic to prefer any version found in the pre-query where we read the package.json, but this SDK would still be out of conformance because it should be sending a version.

Frassle avatar Apr 15 '24 17:04 Frassle

@gio-pcb I think we'll need a bit more information about your program to try to diagnose which resource isn't sending the version. If you'd be willing to run your program with verbose logging and share those logs with us the problem should be clear.

mjeffryes avatar Apr 22 '24 14:04 mjeffryes

@gio-pcb Are you still experiencing this issue, or is it gone now and we can close the issue?

mikhailshilkov avatar Jun 05 '24 11:06 mikhailshilkov

@mikhailshilkov apologize for the delay. We are currently sticking to the workaround as it is good enough for us.

gio-pcb avatar Jun 05 '24 12:06 gio-pcb

FYI, I believe https://github.com/pulumi/pulumi-eks/pull/1190 will fix this issue.

justinvp avatar Jun 08 '24 19:06 justinvp