Skip to content
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

Working with GitHub code spaces #337

Open
rayjlinden opened this issue Aug 3, 2024 · 1 comment
Open

Working with GitHub code spaces #337

rayjlinden opened this issue Aug 3, 2024 · 1 comment

Comments

@rayjlinden
Copy link

I'm trying to get nb to work with codespaces. However, GitHub creates the token you use to access repositories automatically. By default it only allows access to the repository where the devcontainer was defined.

You can edit .devcontainer/devcontainer.json file to give access to other containers. This works well to give access to most of the repos in our org to make development work well for all of our users. But you can't use this mechanism to add access to a "personal" repo like I have set up for nb.

This is making it impossible to have nb setup and working when a new Codespace starts up. Bummer!

But maybe there is a way to do this I'm not aware of yet? Do others have experience trying to get nb auto set up in code spaces? Any help or guidance would be appriciated!

@boldandbusted
Copy link

This comment has no direct solution, sadly.

That said, I took a look at Codespaces, and I think what you are seeing is really Codespaces working as designed... Its authorization story is oriented around either a personal GitHub Account or a single Organization. This story doesn't include repos owned outside those administrative domains, AFAICT. :/

It seems like the path with least resistance would be to have a repo associated with an account that is part of the Organization. Is this not possible for you?

If it is any help, today I tested some scenarios where there was shared access to a GitHub repo with a single nb notebook. Perhaps that's another path - creating an Organization-wide 'instance' or repo? No, it won't scale beyond maybe 10-15 concurrent users due to possible timestamp conflicts (perhaps scaled if the timestamps expand to milliseconds...), but for a small team, perhaps it could work?

Hope this helps somewhat. Cheers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants