Global Environments

[sanbhattdeep]

Environment object should be a separate entity by itself and not be stored inside a collection.
Currently we are not able to share environments across collections due to this

[helloanoop]

Hi @sanbhattdeep

This is actually by design.

In the postman world, Workspaces are the first class citizen, Collections and Environments are under workspaces. This paradigm has been the defacto way of thinking for a decade, and every other alternative (Insomnia, Hoppscotch etc) start with the same paradigm.

With Bruno, we see collections as a first class citizen. Everything related to a collection resides inside the collection including env variables. If you have a payment service, you would save your bruno collections inside a collection folder like below.

payments-api
  |-- src
  |-- collection
       |--environments
           |-- prod.bru
           |-- stg.bru
       |--get payments.bru
       |--create payment.bru

If you are not storing bruno collections inside a repo, but you are using a separate git repo to store collections, that is also fine.

I have two questions

1. Are you exploring bruno for personal use or are you using bruno in a project with some team members?
2. Other than urls, what kind of variables are you storing in environments ?

[sanbhattdeep]

1. Am currently exploring bruno for personal use and may recommend for official use in project later
2. Am storing mostly urls in environments, since the urls will be same across multiple services say payment, order etc.. for running multiple collections in same environment say test i need to duplicate the environment across each collection

[helloanoop]

Nice!

One way to quickly clone environments is to copy the environments folder of your previous collection to the new collection.

You can copy folder using file explorer or do it via vscode by open collections inside vscode.

At this point, i don't think we may support global environments, as we see collection as the first class citizen, and everything related to collection (envs, vars, tests, scripts) resides inside the collection

[helloanoop]

One of the options I am thinking is to support a flow in the UI for importing environments environments from any other collections.

[victor-marino]

Hi!

Sorry to bump such an old issue, but I just came across Bruno (which I love, by the way) and stumbled upon this issue after importing my second collection.

I get what you say about seeing collections as the first-class entity here. But in the end, that is highly dependent on the specific projects you're working on.

For instance, in my case, things look more like this:

project-root
  |-- dev-env
       |--api-1
           |-- GET
           |-- PUT
           |-- DELETE
       |--api-2
           |-- GET
           |-- PUT
           |-- DELETE
       |--api-3
           |-- GET
           |-- PUT
           |-- DELETE
  |-- staging-env
       |--api-1
           |-- GET
           |-- PUT
           |-- DELETE
       |--api-2
           |-- GET
           |-- PUT
           |-- DELETE
       |--api-3
           |-- GET
           |-- PUT
           |-- DELETE
  |-- production-env
       |--api-1
           |-- GET
           |-- PUT
           |-- DELETE
       |--api-2
           |-- GET
           |-- PUT
           |-- DELETE
       |--api-3
           |-- GET
           |-- PUT
           |-- DELETE

So all APIs share a common ancestor - the current environment. That means they ALL have the same base URL, same OAuth2 endpoint, same client credentials and tokens for OAuth2, etc. etc.

I only listed 3 APIs here, but we actually have dozens of them. So the main benefit I get out of using environments in other clients (Postman, Insomnia, etc.) is for different collections to share the same env variables, and being able to switch between environments with a single click.

If my understanding is correct, the only way to do this in Bruno would be to create a single, huge collection for our whole project, and nest all our APIs inside it by creating a folder for each of them. But then, that would require having folder-level variables as well, so we can reuse variables across different methods (e.g.: same API endpoint).

Ultimately, I think this is the reason why most popular clients have structured things that way. Otherwise you're very limited when it comes to automation, and you have to repeat variables in lots of places.

Just my 2 cents, in case it makes you reconsider the feature! ;-)

[helloanoop]

@victor-marino Definitely considering to support Global Environments at the app level.

I'd like to understand your structure a bit more.

payment-service
  |-- dev-env
       |--payment-config
           |-- GET
           |-- PUT
           |-- DELETE\
  |-- staging-env
       |--payment-config
           |-- GET
           |-- PUT
           |-- DEL

Can you elaborate why your structure duplicates the payment config requests. Is it because the data that is being used while you test each environment is different ?

If my understanding is correct, the only way to do this in Bruno would be to create a single, huge collection for our whole project, and nest all our APIs inside it by creating a folder for each of them.

Can you talk about the project a bit more (if it is possible)?
If you are coming from the insomnia/postman world how were you collaborating with teams? - paid plan OR write it to a folder and share via git or google drive (etc)

Also, in your directory structure - you have project-root. Is this a directory where all your collections were saved ?

Hope you don't mind sharing some more details. It'll help me come up with a solution that is comprehensive.

[victor-marino]

Sure, happy to elaborate!

Maybe my diagram above was a bit confusing, as I was trying to show the env dependencies, not how I actually structure my collections in Postman.

At my job, we develop multiple APIs that we expose in a common platform for customers to use. As a result, the structure of all our APIs is something like:

Dev env:
https://dev.our-platform.com/api1-path/
https://dev.our-platform.com/api2-path/
...
Staging env:
https://stg.our-platform.com/api1-path/
https://stg.our-platform.com/api2-path/
...
Prod env:
https://our-platform.com/api1-path/
https://our-platform.com/api2-path/

That means all our APIs share the same base path, OAuth2 path, credentials, etc. per environment.

So in Postman I just have one collection per API, like this:

Workspace-1
   |--api-1
       |-- GET
       |-- PUT
       |-- DELETE
   |--api-2
       |-- GET
       |-- PUT
       |-- DEL
   ...

In each collection, the base path, OAuth path, credentials, etc. are all configured as env variables. And because environments are shared across collections, I only have to set them (and maintain them) once, and not once per API.

If you are coming from the insomnia/postman world how were you collaborating with teams? - paid plan OR write it to a folder and share via git or google drive (etc)

No, I've never used any sharing or paid features. We typically test these things individually, which means each of us may have their own workflow. However, I'm aware most devs at my workplace use the same kind of structure that I use when it comes to collections and environments, which makes sense given our platform structure.

When somebody needs a collection for one of our APIs, we'll will typically export it in Postman (json) format and just send it over teams/email/etc.

Also, in your directory structure - you have project-root. Is this a directory where all your collections were saved ?

No sorry, I was just referring to the structure of our platform (with a root base path for the root domain of our APIs). Sorry for the confusion.

In the end, the key point here is that typically:

• 1 collection = 1 API
• 1 environment contains multiple APIs

As a result, we need the ability for multiple collections to share the same environments, which is typically achieved by grouping them in workspaces in other apps. Otherwise we'd need to duplicate all our environments inside each collection, which would defeat their purpose altogether.

Hope that's a bit clearer.

[AlanSandovalDev]

@helloanoop
We have the same scenario. We are migrating from Postman but we are facing this limitation: there is no global environments 😔
Here I explain our case: #883

We hope you can consider global environments. It's the only thing Bruno is missing.

[helloanoop]

@AlanSandovalDev Will definitely support this as soon as we can.

[David-Lannion]

This issue seems quite related with #292

[edbrannin]

Hi @victor-marino, I'm just some rando, trying to understand your use-case better...

Can you elaborate why your structure duplicates the payment config requests. Is it because the data that is being used while you test each environment is different ?

I think @helloanoop was asking why your structure was using folders to separate environments, instead of something like this:

- Collection: our-platform.com
  - Folder: api-1
    - Request: GET
    - Request: PUT
    - Request: DELETE
  - Folder: api-2
    - Request: GET
    - Request: PUT
    - Request: DELETE
  - Folder: api-3
    - Request: GET
    - Request: PUT
    - Request: DELETE

...with the differences between Dev, Staging, Prod environments being... environments:

Dev env:
BASE_URL=https://dev.our-platform.com

Staging env:
BASE_URL=https://stg.our-platform.com

Prod env:
BASE_URL=https://our-platform.com

So the api-1/GET request would have a URL like {{BASE_URL}}/api-1/, etc.

[thjaeckle]

Hi there.
Thanks a lot for creating bruno - I already love it.

While migrating postman collections and environments to bruno I stumbled across the "shared / global environments" topic.
However, I overcame this by the elegance of bruno, that collections are folders and the environments of a collection is also contained within a folder.

Simply create one directory which holds the environment files and use softlinks for the "environment" directories of the collections, pointing to that shared environment directory.

My folder structure is:

.
├── connectivity-service
│   ├── Test Connection.bru
│   ├── bruno.json
│   └── environments -> ../shared-environments
├── ditto
│   ├── Who am I-.bru
│   ├── bruno.json
│   └── environments -> ../shared-environments
├── exploration
│   ├── Search via POST.bru
│   ├── bruno.json
│   ├── collection.bru
│   └── environments -> ../shared-environments
├── shared-environments
│   ├── dev.bru
│   ├── prod.bru
│   ├── qa.bru
│   └── IDEA.bru
└── wot
    ├── Get Thing.bru
    ├── bruno.json
    └── environments -> ../shared-environments

When I create a new bruno collection, I simply create the softlink to the shared-environments:

cd wot
ln -s ../shared-environments environments

This softlink can even be committed to a Git repository - and at least on UNIX systems works out of the box.

With that, I am able to use "shared environments" across all my collections.

[Jzerbib69]

Hi, i tried to do the same things than @thjaeckle,
but i keep the error : EISDIR: illegal operation on a directory, lstat

Have you an idea, i execute the command : ln -s ../global-environnements environments in the directory Evenement

[ldng]

I having the same problem. To stay true to your manifesto this need can be framed differently. More than a global Environment, the issue is more not to be able to have a Shared Environment.

When you have a micro-service architecture, I want to have collection for each of my services, but I also want be able to run authentication collection once, set my TOKEN in a Shared Environment, and just have those other collections reuse that TOKEN.

I hope it give more insights or another light to the problem.
Great work on Bruno BTW.

[dj-fiorex]

Hi there. Thanks a lot for creating bruno - I already love it.

While migrating postman collections and environments to bruno I stumbled across the "shared / global environments" topic. However, I overcame this by the elegance of bruno, that collections are folders and the environments of a collection is also contained within a folder.

Simply create one directory which holds the environment files and use softlinks for the "environment" directories of the collections, pointing to that shared environment directory.

My folder structure is:

.
├── connectivity-service
│   ├── Test Connection.bru
│   ├── bruno.json
│   └── environments -> ../shared-environments
├── ditto
│   ├── Who am I-.bru
│   ├── bruno.json
│   └── environments -> ../shared-environments
├── exploration
│   ├── Search via POST.bru
│   ├── bruno.json
│   ├── collection.bru
│   └── environments -> ../shared-environments
├── shared-environments
│   ├── dev.bru
│   ├── prod.bru
│   ├── qa.bru
│   └── IDEA.bru
└── wot
    ├── Get Thing.bru
    ├── bruno.json
    └── environments -> ../shared-environments

When I create a new bruno collection, I simply create the softlink to the shared-environments:

cd wot
ln -s ../shared-environments environments

This softlink can even be committed to a Git repository - and at least on UNIX systems works out of the box.

With that, I am able to use "shared environments" across all my collections.

Does this method still work? does it also work on mac?
Because i just tried, and Bruno didn't see anything in the enviroments.
This is the command and the output

Tests % mkdir environments
Tests % ln -s ../SharedEnv environments
Tests % ls environments 
SharedEnv
Tests % ls -l environments 
total 0
lrwxr-xr-x  1 carmelofiorello  staff  12 Apr  3 19:48 SharedEnv -> ../SharedEnv

Thanks!

EDIT
tried also via UI

but nothing, and i can't create an environment through the UI with an error

[SakshiSharmaz]

its a little hacky but,
we can also just add all our collections into one directory ( as sub directories ), the one that has the environments. and then all the api's in sub directory will be able to use the environment in parent directory which is the main collection

• import a collection, import your global environments into that collection
• import all other collections and then from file explorer move all other collections into the one that has your environments.

[busy-panda]

This is a long running story...
I agree with the big amount of users that we are missing global environments, and it is a big limitation compared to postman for example.
In our case we have plenty of microservices hosted in the same host, and we need to duplicate the environment variables and secrets for this host into each microservice test collection.
Or there is the hacky trick with the symlink but that is not nice.

[acuenca-facephi]

I agree too, Bruno is awesome but I think it must have global and collection editable variables such us environment variables.

In my case, to use collection vars I have to setup pre-request vars, also these variables can not be secrets, so I have to use .env files or delete/ignore them to commit the collection to a repository.

[iucn-applications]

+1

[phen0menon]

Only one thing stopping me from migrating to Bruno - global variables absence :(

[jfraullodra]

I agree, I generally use one collection per api, but I can have several api on the same environment. In my case one oauth2 server and api servers. it's a pain to have to copy every environment.