Nested Environments?

[drventure]

Just learned about Bruno and really liking it so far.

I'm coming from Insomnia and one of their fairly nice features is nested environments, where you can have a base environment and 1 or more additional environments nested beneath it that include (or override) variable values in the base environment.

I couldn't find any mention of that in the docs, so if it's not there now, I'd like to suggest it as a possibility.

Thanks!

[danielraab]

Would like this feature too. It is very helpful if you have a lot of environments.

[helloanoop]

I have used the nested environments of insomnia in the past and like its benefits of have a base env and other env's extending the base env.

The reason why I went ahead with a simple key-val (like postman) was just because of its simplicity.

Is there a plan to support nested environments ?

Yes, In V2 - see roadmap

I imagine allowing a configuration in bruno.json that allows people to choose the environment type. something like

{
  "version": "1",
  "name": "bruno-testbench",
  "type": "collection",
  "nestedEnvironments": true
}

[drventure]

Definitely this. Insomnia's environments are a pretty simply structure. Take the base, then iteratively apply each level of nesting to the base, till you get to the selected environment.

There's also an additional slight twist to this.

Each FOLDER that you create can also have environment overrides (that are applied lastly).

This allows you to group those requests that have similar environment requirements together and override base env settings for that specific group.

[bbbco]

This is one of the primary hangups preventing me from migrating completely to Bruno. I'm still using Insomnia ... I reverted 2023.4.0 because of issues experienced in 2023.5.x and never did upgrade past that when I saw all the headaches with forcing users to sync with the cloud. 2023.4 has its own issues and slowness and quirks. I'd like to find something more stable and local and Bruno seems to fit the bill.

[Faqual]

Likewise, nested env and nested variables are the main things making me hesitate to migrate immediately

[benyamynbrkyc]

Nesting environments and variables and having these configured by workspace would be fantastic. Would switch immediately

[minamz]

Yes please I have a use case for testing with different users or different cases in the same env, and this would fit very well

[lauhon]

Would also love this!

An easy alternative for Bruno could be to just enable referencing environment files within another. If it is a good first issue I'm happy to contribute :)

[drventure]

Was playing around a little more with Bruno looking for a way to resolve nested environments.

One thing I noticed is that variables from .env files don't seem to ever be "resolved".

What I mean by that is say you have a .env file like this

var1=value1 var2=custom{{var1}}

when you actually use var2 in a request somewhere, it ends up as a value of "custom{var1}}" and not "customvalue1"

I tried several different syntaxes for self referencing in a .env file, for instance

var1=value1
var2=custom{{process.env.var1}}

and

var1=value1
var2=custom${var1}

among others but nothing seemed to work.

If variable values were dereferenced when used "all the way down" so to speak, that might be an alternative to nested environments in the short term.

In the long term, I still suspect that nested envs would be the best was to solve the problem and keep environments as DRY as possible.

[simonhaenisch]

This is a bit of a blocker for me to use Bruno which I otherwise like quite a lot. I have a different use case than the usual staging vs prod environments, where each environment refers to a different customer, so my issues with Bruno are:

1. different secret values per environment (i.e. they can't go into the .env file, and adding them in the environment in vars:secret is also not sufficient cause I don't want to manage them via UI)
2. some variables that are shared for all environments

I've been able to work around these a bit, by putting shared variables in the .env file which I'm planning to commit, and writing a pre-request script on the collection level that loads values from a .env.<environment-name> into variables when a file exists matching the current environment name:

script:pre-request {
	const { join } = require('path');
	const { existsSync } = require('fs');
	const dotenv = require('dotenv');

	const dotenvFileOfCurrentEnv = join(bru.cwd(), `.env.${bru.getEnvName()}`);

	if (existsSync(dotenvFileOfCurrentEnv)) {
		const { error, parsed } = dotenv.config({ path: dotenvFileOfCurrentEnv });

		if (error) {
			throw new Error(error)
		}

		for (const [key, value] of Object.entries(parsed)) {
			bru.setVar(key, value);
		}
	}
}

But now that I'm using the .env file for shared variables, I can't use it for shared secrets anymore.

Would really like to see a solution for this, i.e. basically the possibility to set a base environment.

[hippasus]

will folder level variables be done in the feature as well?

Insomnia has this folder level environment, it overrides global variables, and can also populate new variable that can only be seen for the request under current folder or sub folders. @helloanoop