Consider an app which, in 12-factor style, receives its config in the form of a JSON document provided as an environment variable. The config contains secrets, so it is never stored on disk; instead, it is computed on the fly before starting the app, using something like sops or nunjucks.
I am trying to debug such an app in VS Code. Is there any way to run some arbitrary script before launch and provide its output to the app as an environment variable?
I will accept answers for any language or runtime, but an approach that works with package.json scripts or Node.js binaries (e.g. Jest, Playwright) would be most helpful for me.
Related
I am currently Using Pytest though the Python Test Explorer (see screen). I would like to pass my tests some environment variables at runtime. However, I currently get my AWS Parameter Store BEFORE I run tests. Meaning, I run a command in BASH that loads my environment variables into my current terminal session. Then I can run my test from the command line using pytest exampletest.py, and it finds the environment variable perfectly.
Trying to run exampletest.py from the integrated VSCode Test Explorer results in an error telling me that it could not find my environment variable. This means that whatever environment that is used when you hit the "Play Button" on the Test Explorer is not the same terminal session that I set my environment variables in.
The conventional way of setting environment variables such that they can be accessed when using the Test Explorer in VSCode is by either using an ini file or a .env file. The only caveat there is that you must hardcode the key value pair. I would not like to hardcode anything, as I would just like to inject them in at runtime from aws Parameter Store.
I really would like to continue using the Test Explorer to run my tests, as it has been great in the past, but if I cannot find a way to somehow get the Test Explorer to use my environment variables without using an ini or a .env file, I may have to abandon it.
Some questions:
When you click the play button on the Test Explorer to execute a test or suite of tests, what exactly happens? Does it open a Terminal session? Can you access that terminal session before runtime?
How does the Test Explorer set environment variables. When I raise Exception(os.environ), I can see all the environment variables that are quite different from the ones that I get when I run from the command line.
Is there a way to say "Hey Test Explorer, please run the tests inside of this specified Terminal window that is already running"
Perhaps a virtual environment is a way to go (not really a question more of a thought). Doing some cursory research reveals more headaches to come if I pursue this route I believe.
Do you have any further reading about that VsCode Test Explorer that goes beyond the official documentation. I feel like I can make some changes to it's source code or something, but I feel like documentation on it is a bit lacking.
Let me know your thoughts on this matter, and thanks in advance.
I have the same question. The only way I could make it work was by this unwieldy series of steps before running the tests via the vscode UI:
Execute your script or command in a terminal to set the env
variables.
Copy those env variables into your .env file (placed at the root of your project/vscode-workspace). I usually do :
env | grep AWS_ or whatever you want and you'll see them as name-value pairs. I then copy and paste those entries at the bottom of the .env file each time I run the test via the UI.
Now execute your tests via the vscode UI (the test 'beaker'/flask). The testing UI/flask seems to execute the .env file every time before it runs the tests and hence picks up those env variables.
I know, it's not preferable - you would want it to just pick it up from the env values you see in your integrated terminal but so far that is not happening.
I'm trying to configure properties for the Google Cloud SDK in a non-interactive environment (specifically, a Docker container), and I'd like to use environment variables to do it (because it seems much simpler to get right and portable compared to volume-mounting config files...). However, I can't find any documentation on what the environment variables should be called, etc.
Is it possible to configure the Google Cloud SDK using environment variables, and how do I do so?
Clarification: For now, the only property I care about is the default project, core/project in this listing.
There is a set of environment variables (CLOUDSDK_) that match some (all?) of the gcloud config properties.
I was unable to find these documented but I'm aware of them through the kubectl Cloud Builder (see here) and this post
I've submitted an issue asking Google to document these (more clearly).
I want to support the usage of 'debugger' statements locally and on the development deployment but not when it gets to staging or production.
I'm using Ember-cli with environments and am not understanding how to define the jshint or eslint directives differently.
By design we can configure both linting libraries differently via their configuration files for app code & test code via .eslintrc or .jshintrc files which reside at the root folder and the tests folder. So even though we can have different rules for these categories of code, we can't differentiate them per environment.
The reason it might not make sense to do so is because the assets that get generated after the build process that gets deployed doesn't necessarily need to conform to these rules since transpilers like babel (may) optimize generated code for us.
While I don't understand the need to keep debugger statements after a debugging session in the codebase, you can use broccoli-strip-debug to remove them automatically in production builds and disable the debugger flag in the linting configuration altogether which gets you the setup you're looking for.
I'm in the process of trying to write a VSCode extension to support basic SNES application development. I already have a basic grammar definition and build task, so I have syntax highlighting, and am able to build my project with Ctrl+Shift+B using the bass v14 assembler, but now I'm trying to figure out how to launch the project using launch.json. I've already worked through the official docs and played around with the mock debugger project, but I can't seem to figure out how to adapt it for my extension. To start, I'm using the bsnes-plus emulator as my debugger. There isn't really any command-line or IPC interface that will actually allow me to implement a proper debug adapter, so all I really want to do is to run the program and pass it my output file to launch. For the time being, I'm assuming that bsnes-plus.exe is located in my $PATH, but eventually I'll try and figure out the best practices for external executable dependencies for an extension.
So here are my current questions:
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
At one point, I was able to get the launch command to open bsnes-plus, but not load the game, and when I closed it, VSCode complained that the debugger terminated unexpectedly and immediately re-opened bsnes-plus. How do I avoid this? Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
This is entirely up to the debug extension. It's just passed through to the debug adapter. It usually corresponds to the specific app/script being debugged though, not the runtime that's running it, so I would suggest it should be your compiled application.
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
You can put it any other field. In Dart, we have a dartPath field that can be passed through to the debug adapter. It's usually populated silently by the DebugConfigurationProvider.resolveDebugConfig though (we detect the SDK by searching PATH) so the user never needs to add it.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
You can't make your own variables, but using resolveDebugConfig you can manipulate the launch config yourself before it's passed to the debug adapter, which probably allows you to do what you need here (eg. you could do a string replace on program - or you could even just add it if it's not set, allowing a launch.json-less launch too).
Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
I'm not sure what happened here without more details, but having a debug adapter probably makes the most sense - for example if you want to make the Stop/Restart buttons work on the toolbar, you'd probably want a debug adapter that can terminate and/or restart the process.
We have a GWT Application that has to link another Application.
This link is different in all stages of my application (local, test, staging, prod). What options are there to configure a GWT app?
Currently we're using properties files for every environment. The problem with this solution is, that we have to create different packages for all the environments. That's bad and we want to build one single package that is deployable to all environments.
But how can we tell the application which configuration to use?
If you are lord of the rings fan -
One Build to rule them all, One Build to find then,
One Build to work on all and in the environment bind them
In the Land of Testing where the Shadows lie.
Solution at our workspace
All the environment specific properties file are pushed into template folder ( log4j_prod.properties,log4j_stage.properties, hibernate.properties etc )
Prod properties file are default and pushed to WEB-INF/classes
QA team modifies the property files using the template files for any other environment.
I too would be curious if it is done any other way :)
If you want to know weather the application is running in which mode , there are some static methods in GWT class .
isClient()
Returns true when running inside the normal GWT environment, either in Development Mode or Production Mode. Returns false if this code is running in a plain JVM. This might happen when running shared code on the server, or during the bootstrap sequence of a GWTTestCase test.
isProdMode()
Returns true when running in production mode. Returns false when running either in development mode, or when running in a plain JVM.
isScript()
Determines whether or not the running program is script or bytecode.
etc....
Based upon tha flags you can configure the folder name of the properties