-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could not resolve Private Feature when pre-building a Codespace (not a container image) #277
Comments
Locally you just need to sign into the docker CLI for your private GHCR registry. @joshspicer @jkeech I assume this needs to be added to devcontainer.json to access private features for codeespaces? Might need better notifications about it in Codespaces if so.
Also note that any container registry you are signed into (either via the Docker CLI locally, or Codespaces' support for private container registries) can also contain Features for you to use. The above json just does it without an explicit login for Codespaces specificially. |
Thanks, I already had this in place JSON metadata below, but noticed today that it might turn off "write" as indicated by the strikthrough in the screenshot. I tried adding your explicit example and still got the same error. Even after I remove my wildcard permissions. I'll do some more investigation to see what the root cause may be, but still feels like a bug. Does it help the the features created at customink/features uses the CLI GitHubAction? Could it be a permission issue for some reason? "customizations": {
"codespaces": {
"repositories": {
"customink/*": {
"permissions": {
"contents": "write",
"packages": "read"
}
}
}
}
}, |
OK, I found the issue. My project is using |
Hmmm. Not catching the scenario where it was and wasn't working since you're showing codespaces pre-builds and mentioning Actions. The privs for the two products aren't unified is part of this since you, to your point, you likely want the "write" permission in some cases there ... like where the feature originates. You can set both from the configuration for the OCI Artifact in GHCR: It's the same setup as images, so if you can access a private image in GHCR, you should be able to access features. The Codespaces json is a shortcut to enable cross-repo access for Codespaces exclusively. I wouldn't expect Compose or image to have any impact. If it does then it might be a Codespaces bug - not entirely sure. If that's what you are seeing though, @jkeech @joshspicer @edgonmsft @samruddhikhandale might have an idea of what could be going on there. Folks, are there any known issues with Docker Compose-based codespaces? |
Our customink/features repo uses the I think core issue is the prebuilds do not work with the private features if I am using kcollins:
build: { context: ., dockerfile: Dockerfile }
command: sleep infinity
privileged: true
user: vscode |
Ok - managed to repro. Works fine building the Codespace w/o a pre-build, so this it is very specific to pre-builds with private features like you said.
The interesting thing is @jkeech @joshspicer @edgonmsft @samruddhikhandale - LMK if you can repro or I can give you access to my repro. The fact that the same setup works for non-prebuilds in Codespaces means its likely not CLI related tho. |
@Chuxel Can you give me access to your repro? |
@edgonmsft https://github.com/Chuxel/compose-private-feature-test is the repo - made it public, but added you as a collaborator so you can see the actions logs. The feature referenced is in https://github.com/Chuxel/feature-library/tree/main/src/test-private-feature. I just have access on the resulting OCI Artifact set to private. |
Thanks @Chuxel it does look like a permissions issue in Codespaces, we are investigating. @metaskills could you give us more information?
|
Agreed!
No, nothing has changed since reporting the issue. Still not working with private features and docker compose.
customink/codespaces-kcollins
Yup, I tried this multiple times. Still does not work.
No, the repo I am using is private, and the feature packages are private. I would not feel comfortable switching them to public to test this. But I can say other public packages work. And private ones work too, just not with prebuilds. |
@metaskills does it work if you change the package security to |
Sorry, not sure what that means. The devcontainer/ci action publishes these packages on my behalf. If I view them in the repo they are listed as "private". What is "internal"? |
@metaskills, did you ever get this working? I did some searching and found that for private packages, you need to declare permissions bi-directionally in two places: in the consuming repo and in the publishing repo.
After those two steps are done, prebuilds should work. This flow is pretty complicated, and I'm following up to see if we can make it simpler. Let us know how it goes! 🙏 |
Thanks for the followup to this, I have not yet had the time to confirm but will use this info when the prebuilds priority comes back up again. Thanks!!! |
Cool, that worked. I also found out about the Did not try this method but I suspect it would have worked as well. Maybe we can close this issue? |
Glad to hear it worked! Yes, I think either approach would work, although managing the PAT manually with the Closing this issue as requested. |
So we have several private features at our org
customink/features
and I was hoping to do a prebuild with some projects an noticed the CLI raised aCould not resolve Feature
error even though I granted the prebuild the needed permissions during creation time. Is this a bug?The text was updated successfully, but these errors were encountered: