Comments (19)
@AlanSandovalDev Will definitely support this as soon as we can.
from bruno.
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.
from bruno.
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! ;-)
from bruno.
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.
from bruno.
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.
from bruno.
One of the options I am thinking is to support a flow in the UI for importing environments environments from any other collections.
from bruno.
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.
from bruno.
@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.
from bruno.
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
- Are you exploring bruno for personal use or are you using bruno in a project with some team members?
- Other than urls, what kind of variables are you storing in environments ?
from bruno.
- Am currently exploring bruno for personal use and may recommend for official use in project later
- 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
from bruno.
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
from bruno.
@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.
from bruno.
This issue seems quite related with #292
from bruno.
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.
from bruno.
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
from bruno.
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-environmentsWhen 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
from bruno.
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.
from bruno.
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.
from bruno.
+1
from bruno.
Related Issues (20)
- CLI does not apply AWS Sigv4 to requests when the AWS Sigv4 is set at the collection level using environment variables
- License activation error
- REGRESSION: static/diff2html.min.css:1 Failed to load resource: net::ERR_FILE_NOT_FOUND & Error invoking remote method 'send-http-request': TypeError: Cannot read properties of undefined (reading 'get') HOT 1
- Post with application/x-www-form-urlencoded and TEXT body won't pick up environment variables.
- Bruno crashes when trying to save Multipart Form Requests with certain values HOT 1
- Bruno desktop app should automatically update when there is a new release.
- Docs - Support for Mermaid Diagrams
- Bruno can't Handle 303 Response HOT 1
- Notification of the release of a new version can be given
- CLI does not update environment variables
- Disable proxy option not working HOT 8
- Add a new Assert : isArray HOT 2
- Extremely slow project opening HOT 3
- [BUG] Having query{} on a GET request makes bruno to not recognize changes on file HOT 1
- [Feature Request] Store client certificate paths in collection settings as relative to collection
- [BUG] Poor responsiveness of application when using big collection e.g. 3000 .bru files
- [BUG] In documentation are tags that are not implemented in Application -> CONNECT
- [BUG] In documentation are tags that are not implemented in Application -> TRACE
- [BUG] At https://www.usebruno.com/downloads links aren't to newest version
- Cannot send two values with the same key with Form URL Encoded HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bruno.