How to share/allow all organization members to access my codespace?

[hsein-bitar]

Select Topic Area

Question

Body

I would like to make the codespace that I create be open to my organization members by default.
I would like to avoid having to start a live sharing session and using extensions.
Also, it would be ideal if the solution is cli based - so that I can automate this authorization process.

I can't find any documentation for doing that, any help is appreciated.

[joshspicer]

Thank for the question @hsein-bitar! A single codespace is today scoped to a single user, there is no way to grant someone access to a specific codespace and have it show up in their list of active codespaces. That said, we offer a lot of tools to configure a repository to quickly create identical, isolated codespaces for all the members of your team (configuration via the devcontainer.json, repo-scoped secrets, prebuilds, etc.)

If your goal is to share demos of a project running on the machine, you may consider forwarding a port and setting it as public.

Your request is analogous to all team members allowing persistent access to one's dev machine. I'd love to learn further why you find this uniquely useful (and why existing solutions like Live Share aren't sufficient).

[tylerdigital]

Thanks @joshspicer, I would like this for passing a codespace between our devlopment and QA teams. For example, QA finds and replicates an issue (reproducing the bug may include database state changes inside the container). Then I'd like a developer to log into the same codespace, make some code fixes, and pass it back to the QA team for testing (all happening in a single codespace dedicated for a PR).

So I think what we're missing is how to have a shared database isolated per-PR. The port forwarding sounds helpful for live joint debugging, but much of this would need to be asynchronous with people being online at different times.

Do you have any other recommendations on how to approach this?

[joshspicer]

Hey Tyler - that makes a lot of sense. We don't have any native support today for something like this in codespaces.

That said, there's definitely some ways to do this out of band that would be specific to your project but could benefit from the many features and ephemeral-ness of codespaces. An idea off the top of my head that would require a bit of engineering, but likely be very useful in the end for your use-case:

1. As a one time setup, create some centralized storage that can easily be pushed/pulled to (azure blob storage, amazon s3). Add a repo-scoped secret and some script snapshot_upload.sh to your repo that can take/upload a DB snapshot.
2. Devs spin up a codespace and make some change that they want QA to take a look at
3. Run, snapshot_upload.sh, which looks at the DB and other files, uploading to some blob storage your company controls

Now the QA team creates a codespace from the PR, but with a different custom dev container with a
lifecycle hook script that looks into the blob storage for any snapshots and is configured to pull down the snapshot from that storage and apply it.

The internals of snapshot_upload.sh depend on your particular configuration. Say you have a mysql database, you could do something like https://linuxize.com/post/how-to-back-up-and-restore-mysql-databases-with-mysqldump/ and then azcopy to upload to blob storage, and the reverse in the lifecycle script to apply it automatically. Perhaps you employ some naming convention corresponding to the PR number such that you can automate as much of the process as possible. eg: running this gh command inside a codespace tells you the PR number:

@joshspicer ➜ /workspaces/features (patch-1) $ gh pr view --json number
{
  "number": 566
}

[joshspicer]

That all said, this use-case is an interesting one that i've brought back to the team for discussion!

[wassx]

Hi @joshspicer, any news on that please? I know this from gitpod and this a very useful feature the team highly appreciates.
To add more context:
In our company, tools like live share are blocked due to security reasons. Sharing a snapshot, quickly allows to report an issue/ask a question, without branching and so on. But the shared snapshot will be opened and code executed with the actually logged in user, not the sharing host.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬