Environment variables are not saved to the disk when using bru.setEnvVar()

[gcharondkt]

I have checked the following:

• [X] I use the newest version of bruno.
• [X] I've searched existing issues and found nothing related to my issue.

Describe the bug

1. Create an environment
2. Run the request
3. Open the variable : the "key" is there
4. Quit Bruno and reopen it
5. There is no "key" anymore

.bru file to reproduce the bug

meta { name: test type: http seq: 2 }

get { url: http://google.fr body: none auth: none }

tests { bru.setEnvVar("key", "value"); }

Screenshots/Live demo link

N/A

[end3rbyte]

It should be "bru.setEnvVar" in the title (not bru.setProcessEnv) I guess.

Indeed, it does not persist the change in environment variables, I guess it should.

[Daniel-Byrne]

Is there any update on this? I have the same issue and it renders Bruno practically useless for my needs.

I am using v1.19.0 on Mac Sonoma 14.5.

[helloanoop]

I am not sure if its a good idea to have bru.setEnvVar("secret", token) to be saved to the env bru file. A common use case of people updating the env vars involves fetching a token and saving it to the env var.

When it comes to managing tokens, we recommend to use bru.setVar()

@Daniel-Byrne @busy-panda Can you share some use case examples where we need to have the bru.setEnvVar() write changes to the file?

We can consider an option to pass to like - bru.setEnvVar(name, value, {persist: true})

[alesbolka]

Here's my use case: I maintain the account system for our company and because certain things happen only on account creation, I made a collection to simplify account creation. The "automated account creation" request has a pre-request script that generates a unique suffix for an email and upon success, sets the email as an environment variable as the last generated account. That email can then be used by other requests in the collection to check things. As sometimes development of new features can take a longer time, it's nice being able to go "this was the last account I created" and persist that, as you continue working on whatever comes after account creation. We use this a lot as we have separate teams working on separate features and each team would like to maintain the collections used for their own systems.

I'd be happy with a way to manually call something like "bru.saveEnv" from within the pre/post request scripts to store the data.

The collection variables don't even update visually when setting them from within a script, let alone persist (maybe the latter part is intentional), but that's a separate issue.

[end3rbyte]

I normally use more setVar than setEnvVar, but I understand that it could be useful to be able to persist things that were changed during the collection run.

So I like the idea to have the option to set the var and save the change like you suggested @helloanoop :

bru.setEnvVar(name, value, {persist: true})

[gcharondkt]

@helloanoop my use case is the following : I have many collections for which I would like to share environment variables. To do so, I have create an env .bru file at root level, then created a symbolic link from the collection's environment to the root environment.

The problem is that when a collection write an env variable, this variable is not readable by another collection. I guess environments are loaded separated in memory.

[jonathanazulay-sileon]

@helloanoop I think this is a good analysis. I just found two minor problems with the scenario

• These env values set using the setEnvVar seem to reset after restarting Bruno (maybe a feature)
• If you view your environments in the GUI and clone Environment A into a new Environment B, it will create a new environment file (B.bru) that contains the env values (that was added with setEnvVar).

[GermanMtzmx]

@helloanoop it will be great to be able to persist env vars values but if you want to implement {persist: true} conf, I'd suggest to set it to false by default, There is a possibility of committing the collection into a repo and expose secrets.

Also you can add a new field into the configure env options to persist the env values. In that way we could cover the scenario of having 3 envs (develop, stagging, prod) configured for a collection, so we can choose in which env we want to persist the values and in that way we don't need to update the post-request scripts by setting {persist:true} for development envs and {persist: false} for prod envs.