We’d like to set default environment variables for a pipeline using the textarea visible when you click “New Build”. We’ve got a few variables that people won’t remember off the top of their head and we’d like to default to false unless someone needs it true.
Is this possible yet?
Came here for the same feature request. Would be nice to be able to set Default Environment Variables in the Pipeline Settings.
This would give users visibility on which variables are available and allow them to modify them a lot easier.
Hey @nathan.pierce and @Aladdin,
We did release a feature of sorts that can work for scenarios like this called Pipeline Templates, it’s an enterprise only feature that allows you to define default steps for Pipeline(s) that you select. This would allow you to create a scenario where you set some default env: values and get them overwritten at a later time.
If all you’re after is just using default environment variables and flipping them later to new values, you could use an Environment Hook (this link brings you to an example of how to do it if you were managing secrets, but the same idea applies to this scenario too) and then attempt to change the ones you’ve set in your hook later on in your steps (either at the root level, or at the step level using env:). I’m not sure if that fits the scenario you folks have described 100%.
Hey @jared ,
Pipeline templates allow us to create pipelines with some common elements already provided but it does nothing when creating new builds of those pipelines through the New Build button.
Environment hooks allow jobs to have environment variables set before running the script based on the agent. This does nothing for creating new builds where you don’t remember what the environment variables are.
This is purely UI/UX without interfering with the pipeline scripts.
Hey @Aladdin
Understand where you are coming from, are you able to give us more insight on how you might see such a feature work in the Pipeline Settings? And would you use such a feature in combination with the other ways of setting Environment Variables e.g., in pipeline.yml, hooks, etc.,?
Additionally, are you able to provide us with an indication of how frequent you/your Organization start Builds using the UI and then sets Environment Variables?
Hi @tomwatt ,
Sure, I can provide such details.
We usually start a New Build from the UI when we want to test a change on a branch. For that test we often need to use specific environment variables for that build.
Currently, we grab those variables from an older pipeline or get them from the pipeline docs as the variable names are a lot to memorize.
I understand that there are defaults already specified in the pipeline scripts, and when you specify those values in the New Build UI they will override the default values in the scripts which can cause confusion here, however it’s already clear to the user that when he writes environment variables in the New Build UI they will be respected.
Hence, my suggestion would be to have a Text field in the pipeline settings page that the pipeline developer can use to provide a default Environment Variables string. It won’t necessarily be all the env variables used in the pipeline but a smaller subset that the developer specifies. The variables can be value-less or have a default value.
An example of what will be Environment Variables Text Field in the Pipeline Settings would be:
TARGET_CLIENT_CONFIGURATION_LIST=
TARGET_SERVER_CONFIGURATION=Test
And when the user want to create a New Build through the UI, the Environment Variables Text Field will get filled from the one in the Pipeline Settings. Then the user can just modify the value of the variable or instead of worrying about whether the variable name is correct or not.
The user can also choose to clear the whole Environment Variables text area if he chooses to.
I hope this clears things up.
Hey @Aladdin
Thank you for such a reply, it’s really detailed and helpful to see what you are looking for and how you are using Buildkite Pipelines. I’ll raise this with our Product Team.
Hi @Aladdin I am from the product team, thanks for the feedback. This is a great idea but unfortunately we don’t have it in our near roadmap. We’ll let you know if that changes.
Thanks a lot!