Those features, at least when it comes to managing secrets, are available, but only with GitHub Enterprise Cloud.

@spol-vt could you provide a link with reading material in the docs to that extended variable management capabilities?

@jnus now that composed actions have much more flexibility (announced a few weeks back) - I am wondering if you would maybe want to create a sort of repository of configuration where all the data lives in JS files, and use an action that works based on that. Kind of like in the concept of GitOps. You’ll manage those variables simply by editing those JSON files.

@lirantal Environments - GitHub Docs

Environment protection rules and environment secrets are only available on private repositories with GitHub Enterprise Cloud. For more information about how you can try GitHub Enterprise Cloud for free, see “[Setting up a trial of GitHub Enterprise Cloud]”

  <a href="https://docs.github.com/en/actions/learn-github-actions/sharing-workflows-with-your-organization#sharing-secrets-within-an-organization" target="_blank" rel="noopener nofollow ugc">GitHub Docs</a>

Sharing workflows with your organization - GitHub Docs

You can centrally manage your secrets within an organization, and then make them available to selected repositories. This also means that you can update a secret in one location, and have the change apply to all repository workflows that use the secret.

There is nothing for classic clear txt vars, just secrets, however since it is basically same difference, you can use it for that purpose. With Enterprise Could one can create Org level, Repo level and then Environment level secrets + there is permission management around access to secrets, etc. Functionality is not as extensive as in products mentioned by @jnus, but there is something that goes towards it.

The secrets per environment are nice if you an enterprise plan. The thing I miss the most is that you can’t have variables that are readable… Why only have secrets? 😅

@spol-vt - So some of the feature set is partly there, in terms of secrets, but not on an organization level though where you can’t scope to environments. We share a ton of variables today via Octopus Deploy, scoped for the various environments, ready to use. This could be resolved in others ways than inheritage (submoduling, npm/nupkg etc), so I’m not seeing this as the biggest challange. Not having a unified and context specific ‘view’ of you variables in you workflow(s), in the really big pain point, where you have to declare all environment specific varibles per environment prior to deploying.

@lirantal Having all variables as secrets will not be easy to maintain, plus I really applaud having everything in vcs.

@ThomasReyskens - It’s a good question - why only have the options to scope secrets per environment and not clear text? My guess is that the GH team also loves having everything in vsc, including configuration and giving the option to save clear text variables on the GH controlplane, violates this principal. A variable framework should definitely based on having the configuration in vsc and having secrets outside, is just a necessary evil to keep sensitive information safe.

@lirantal - regarding composed actions, that might be an idea going forward. Depending on what kind of initiative is going on around the community, I might start to build a variable framework based on the ideas of Octopus Deploy - e.g. variables in a json structure, scopes to environment/workflow/jobs/steps, supports variable substitution and context aware depending on the environment you are deploying to, workflow etc. But I really want to make sure this is not on the backlog for GH, as I want to use vanilla GH if possible 😑

Makes sense, yeah :slight_smile:

I ended up building a “pre-processing” tool for GHA workflows tailored to my company. This included variables, an equivalent to YAML anchors and pre-populating jobs with common steps. Downside is we have to remember to re-run this process every time we change the input workflow, but it makes it much simpler to manage.

@dorner interesting way to go about it. If you are allowed to share any details about your current implementation (publicly/privately), that would be greatly appreciated for inspirational purposes.

Still really puzzled to why this is not on the backlog for the GH team, with all the focus Microsoft is giving GitHub, as this is a big big pain point with larger deployment setups.

@jnus you can see a cleaned-up version of it here: https://github.com/dorner/gha-config This version probably doesn’t work per se because I scrubbed some of it, but that’s the general approach.

Fyi - v1.0 of the action just released → json-variables · Actions · GitHub Marketplace · GitHub