Does Vercel have an inbuilt environment variable for preview deploys (as opposed to production)?
I know that you can set these manually for different deployments, but I assumed this was a common enough requirement that there would be something available by default. However I can't find this in the documentation.
process.env.VERCEL_ENV will be "preview" for preview deploys.
https://vercel.com/docs/concepts/projects/environment-variables#preview-environment-variables
Related
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 IntelliJ. 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 run config type, but an approach that works with "npm" or "Application" would be most helpful for me.
EnvFile IntelliJ IDEA plug-in added this option some time ago.
I did a quick test and don't see this option available, at least on Windows.
EDIT: found it was only merged in the forked version and not available in the official plug-in. You will have to merge it manually and build the plug-in from sources.
IntelliJ IDEA doesn't have a built-in feature for that, feel free to vote for the corresponding request.
I have configured the environment variables as follows:
This resolution is supposed to be compatible with every OS, still tried many others and also different OS.
I applied the same settings for the .env file on the project.
What are the configurations you have provided to initiate your tests?
Since you have specified the flag BROWSERSTACK_USE_AUTOMATE="1", the setting on https://www.browserstack.com/automate/capabilities would come into effect.
Right now I am building a project and using vuejs for the front end. When testing locally, creating a .env.developement and .env.production work fine when in different environments and will show variables correctly. My issue now comes when building in azure devops. I am pointing to the dist folder and this is, obviously, only providing production variables which makes sense.
Is there a way to pass in dev vs prod environment variables to vuejs to build against in a azure devops/vue project?
Seems like there is something "magical" about the way vue is injecting these files into the index.html file and I cant pinpoint how vue is deciding which env variables to use.
Seems to me a question not related with Azure DevOps Pipelines but with Vue compile process.
I don't know a thing about Vue, but if it works similarly to other javascript /typescript frameworks, you should specify the environment in your build tasks.
In my Angular projects I may create a npm task specifying which environment to choose (i.e. npm run build:prod or npm run build:pre). And then, in my Azure Pipelines run the right task depending on the environment I'm going to deploy (you may even store the output in different build artifacts depending on the environment, so you'll have all those artifacts available in your deployment pipeline).
Finally (just a recommendation) I would recommend you to review which values you store in your .env.production file, just to be sure that it's safe to store that file in a repository. If you have some sensitive information, I'd recommend you to use Pipeline Variables instead. Pipeline Variables may be keep hidden, available only for the DevOps Team.
Regards.
I am facing this issue in mfp 7. See the attached image for better clarification.
"wlconcatenatedbody0.js" gets created when you chose to concatenate your JS files. This is a choice you make as part of your build process. The configuration to do this, is enabled via build-settings.xml. Concatenation of JS files is not on by default in Desktop browser environment.
Refer to the steps and details here.
This does not cause runtime issues, but if there is a problem, troubleshooting becomes hard. If you do not wish to have concatenation on, you should modify the settings accordingly.
One thing I really like about the later version of Worklight/MobileFirst Studio is the faster edit/test cycle when working in the Mobile Browser Simulator: just edit, save, click Go/Refresh; no need to build/deploy.
When using CLI (6.3.0.00.20141111-1216) this does not seem to be the case. Seems like I need to do
mfp build; mfp deploy;
After every edit. Am I missing a trick?
Right now I'm thinking I need to revert to my old practice of setting up a web-server to serve directly from my product folder, which is not ideal because I then need to mock up the WL.* APIs I use.
This information from Karl Bishop:
At the current time, this is a limitation of the CLI, based on the use of a standalone MFP Server. Within Studio, some special tricks are being played, to just updated modified files. We are working to resolve this in the CLI and perform similar per file deployments, but we're not there yet. In the interim, I encourage you to view Justin Berstler's video on using the CLI with Grunt.