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
At the moment, the only way to set a global environment variable is to change the configuration of the service itself and restart the Woodpecker application. See here
An example of where I would find this incredibly useful is for image names. Let say that I use one specific docker image throughout a number of projects and I know ahead of time that, periodically, I may need to change that image name. It would be great to easily do so without having to restart the entire Woodpecker platform.
Suggested solution
I propose, in the spirit of #7 and #345 that there be Global and/or Project level environment variables and the corresponding UI editor. These environment variables could be stored in the database and would then be easily made available to all projects.
Alternative
At the moment, the closest solution to this would be to create a secret per-project and then map that to the environment variable, but this comes with limitations. With the fact that secrets are, by design, secret.. there would be no way to easily see what the current value of that secret is. For anything that isn't actually a secret, this would be counter-productive.
Clear and concise description of the problem
At the moment, the only way to set a global environment variable is to change the configuration of the service itself and restart the Woodpecker application. See here
An example of where I would find this incredibly useful is for image names. Let say that I use one specific docker image throughout a number of projects and I know ahead of time that, periodically, I may need to change that image name. It would be great to easily do so without having to restart the entire Woodpecker platform.
Suggested solution
I propose, in the spirit of #7 and #345 that there be Global and/or Project level environment variables and the corresponding UI editor. These environment variables could be stored in the database and would then be easily made available to all projects.
Alternative
At the moment, the closest solution to this would be to create a secret per-project and then map that to the environment variable, but this comes with limitations. With the fact that secrets are, by design, secret.. there would be no way to easily see what the current value of that secret is. For anything that isn't actually a secret, this would be counter-productive.
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: