Unencrypted Environment Variables (like: Not-Secrets)

Secrets are good to pass… well… secrets to your workflows. What about non-secret values that you still don’t want to hardcode in your workflow?
Secrets also do not work everywhere in a workflow, only on the job/step level afaik.

My workflow uses environments with URLs. A fork that wants to run these workflow to test the deployment under a different URL now has to change the workflow file. It would be nice to have some form of repository setting for that. Any ideas how to achive that? I thought about using issues to store configuration but that would be extremely ugly. :smiley:

1 Like

That sounds like a valid use-case indeed.

I guess using secrets would be somewhat misleading as what you want to store might not be a secret, but using them would provide you the same repository-configured type of environment variable that someone can configure in their repos without changing the workflow file.

The limitation I am facing with secrets is this one: Workflow syntax for GitHub Actions - GitHub Docs

“any context except for the secrets context”

And if I remember correctly there are other situations where you can’t use secrets.

Whatever the reason is, I guess it has something to do with not accidentally exposing secrets. Something less restrictive for non-secret values would be nice.

Yep, seems like this is current limitation and perhaps related to not accidentally exposing sensitive information.

That said, you could still set these vars as secrets and make use of them in the job’s steps (sure it’s not the general workflow, but good enough?).

I shared the feedback with the GitHub team too. If anything come ups as a workaround I’ll share with you.

1 Like

Thanks!

I can use secrets, sure, but it is just a bit annoying that I myself can’t even see their current value in the settings, which is good for actual secrets of course.

I currently just read information from config files in my repo as a workaround and actually I’m totally fine with that. I can just imagine that one might want to avoid committing to the repo every time you change such an “environment” variable.

Yep, totally get that!