pulumi / pulumi-eks

A Pulumi component for easily creating and managing an Amazon EKS Cluster
https://www.pulumi.com/registry/packages/eks/
Apache License 2.0
171 stars 80 forks source link

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

Closed gio-pcb closed 3 months ago

gio-pcb commented 5 months ago

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).

Frassle commented 5 months ago

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?

gio-pcb commented 5 months ago

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

Frassle commented 5 months ago

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.

blampe commented 5 months ago

@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.

Frassle commented 5 months ago

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.

mjeffryes commented 5 months ago

@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.

mikhailshilkov commented 3 months ago

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

gio-pcb commented 3 months ago

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

justinvp commented 3 months ago

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