Closed gio-pcb closed 3 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?
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
Thanks I think this is two issues.
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 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
.
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.
@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.
@gio-pcb Are you still experiencing this issue, or is it gone now and we can close the issue?
@mikhailshilkov apologize for the delay. We are currently sticking to the workaround as it is good enough for us.
FYI, I believe https://github.com/pulumi/pulumi-eks/pull/1190 will fix this issue.
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.
I can workaround this by adding a previous step to the workflow as follows:
Example
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).