Devon
My feedback
1 result found
-
10 votes
An error occurred while saving the comment Devon
supported this idea
·
We're glad you're here
Please sign in to leave feedback
Signed in as
(Sign out)
We're glad you're here
Please sign in to leave feedback
Signed in as
(Sign out)
Feedback and Knowledge Base
-
Searching…
No results.
Clear search results
-
Give feedback
- Atlas 1,140 ideas
- Atlas App Services 248 ideas
- Atlas CLI 19 ideas
- Atlas Search 130 ideas
- Charts 213 ideas
- Compass 325 ideas
- Connectors (BI, Kafka, Spark) 35 ideas
- Data Federation and Data Lake 43 ideas
- Database 243 ideas
- Documentation 3 ideas
- Drivers 58 ideas
- Education 31 ideas
- FLE and Queryable Encryption 3 ideas
- MongoDB Analyzer (for .NET) 1 idea
- MongoDB for VS Code 54 ideas
- MongoDB Shell 32 ideas
- Ops Tools 415 ideas
- Realm 82 ideas
- Relational Migrator 1 idea
- Support Website 11 ideas
- UI 99 ideas
we use mongosh as part of our application deployment process where we checkout release-specific artifacts from source code control, build a "work file (.js)" of all changes for the release, then execute that script by piping it into the mongosh. We are not able to retrieve commands or return results of the commands indicating success/failure. Instead, we see something like:
Atlas [mongos] test> myDB
Atlas [mongos] myDB> ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Atlas [mongos] myDB> ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Atlas [mongos] myDB> ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Atlas [mongos] myDB> ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Atlas [mongos] myDB>
Atlas [mongos] myDB> ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
More control over command capture and result verbosity is critical to determining success/failure of a deployment.