You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Yes, for every project's CI now I need to explicitly indicate every env var I need exported so that builds and deployments work. But this becomes tedious and prevents the ability to build projects from templates easily.
Describe the solution you'd like
It's common to use .env, .env.stg, .env.prd etc. files in local development and deploying. I'm using Vault to store the contents of these files entirely and in deployments I'm reading the same files and writing it out as a .env file which is sourced in deployment before executing a workload. It would be great if this action had some sort of mechanism to make this simpler and provide a purpose driven way where it recognizes the use case.
Describe alternatives you've considered
Similar requests appear to made with #336, #234, and #153 but none describe using entire content values as .env files which might be easier to deal with than parsing key/value pairs on all downstream uses like K8s deployments.
Additional context
The CI workflow for a single service I'm using includes provisioning infrastructure, writing out secrets (db names/pws etc.) to Vault, reading them in GHA, building and deploying with them as env vars, and finally injecting them in K8s deployments which source the same env vars from Vault. Not sure if optimal but trying to figure out the best way to make everything automated E2E and secure.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Yes, for every project's CI now I need to explicitly indicate every env var I need exported so that builds and deployments work. But this becomes tedious and prevents the ability to build projects from templates easily.
Describe the solution you'd like
It's common to use
.env
,.env.stg
,.env.prd
etc. files in local development and deploying. I'm using Vault to store the contents of these files entirely and in deployments I'm reading the same files and writing it out as a.env
file which is sourced in deployment before executing a workload. It would be great if this action had some sort of mechanism to make this simpler and provide a purpose driven way where it recognizes the use case.Describe alternatives you've considered
Similar requests appear to made with #336, #234, and #153 but none describe using entire content values as
.env
files which might be easier to deal with than parsing key/value pairs on all downstream uses like K8s deployments.Additional context
The CI workflow for a single service I'm using includes provisioning infrastructure, writing out secrets (db names/pws etc.) to Vault, reading them in GHA, building and deploying with them as env vars, and finally injecting them in K8s deployments which source the same env vars from Vault. Not sure if optimal but trying to figure out the best way to make everything automated E2E and secure.
The text was updated successfully, but these errors were encountered: