Hey! Secrets support is definitely on our roadmap 👍 As you mentioned, the plan is to leverage the existing support for org and repo-level secrets that Actions already uses. That said, since Codespaces is more of an individually-managed service (as opposed to Actions), we’ve also heard a lot of feedback for introducing user-level secrets.

Out of curiosity: how would you imagine your team making use of secrets with Codespaces? Would you have repo/org-wide secrets (e.g. connection strings for shared dev databases), or would you expect to want each developer to have individual, user-level secrets? Thanks!

Hi, thanks for the quick reply 🙂 That’s great that it’s on the roadmap.

I think teams would find both repo/org-wide secrets and also individual, user-level secrets very useful. I think it’s key that individual developers are able to configure secrets for their development environment on an individual basis.

As per 12 factor, I’d see the individual level and the repo level secrets as being independent of each other, rather than trying to group them and to use overrides. Would be very handy to be able to switch easily from having the Codespaces dev environment use individual secrets to using the repo level secrets, and vice versa. I’d see the repo level secrets as typically being the default when creating a new Codespace, which would be useful for people new to a project, for instance.

Hope that’s useful, just throwing some ideas out there :slight_smile:

+1, being able to set environment vars from secrets would be ideal for being able to develop in codespaces.

+1 Strongly agreed around the secrets, especially personal.

From my understanding the ultimate philosophy of Codespaces is one-click, immediate Dev Environment. If we have any remaining manual setup after the automated setup steps then we’ve got a problem.

My current project necessitates using an OracleDB container, to pull that I need to login to Docker. That’s a private environment variable and as part of a developer’s contribution to the repo they will need to provide that.

When I create the codespace for this repo, it should spin up the entire stack, run migrations + seeders, install all needed dependencies, then by the time Codespaces is ready for me all I need to do is start coding. I’m fine to have more manual configuration upfront (re: secrets, build steps, etc.), I’d rather not have to repeat the process every time I made a Codespace (logging into DockerHub, running setup steps manually).

Hi @lostintangent, just wondering if you have any updates on Secrets support - what’s the rough timeline for this on your roadmap? Thanks v much, John

We’re targeting having this available in a few weeks

Is the secrets support there yet ?

@ritz078 they mentioned this question yesterday at GitHub Universe 2020, it should be available soon

Thanks so much for thinking to let me (and this thread) know! Will give it a whirl for sure and let you know how I get on 😎

Just tried using the new secrets functionality and am pleased to say it works a treat 😊

Hey @johnboyes - how did you actually use the secrets in your Codespace? I see Managing encrypted secrets for Codespaces - GitHub Docs for creating the secrets, but no documentation on how to then use/access it within a Codespace.

@scottbrenner, secrets end up as environment variables in the VS Code process and terminals inside the codespace. You should be able to run echo $SECRET_NAME in the terminal to see the value.

Secrets get updated on every codespace creation/resume, so if you update a secret value in the UI while the codespace is running, you’ll need to suspend and resume to pick up the updated value, either by letting it auto-suspend after 30 minutes of inactivity, or by using the VS Code extension to suspend the codespace manually and reconnect.

Are there any plans to expose these secrets as filesystem objects inside codespaces?
The perfect use case for this would be GOOGLE_APPLICATION_CREDENTIALS for authenticating to google cloud. This environment variable is set to the path which contains the account’s json.

Ideally, this feature would work exactly like gitlab’s CI variables where you can designate a variable as a “file” and it will get placed in some location on the filesystem. Then, the path to that location is exposed in the environment variable.

What about build secrets? Maybe I missed it in the docs, but how am I supposed to handle connecting to private package repos when building the container for a Codespace?