How to set process.env.var in devops Azure pipeline - asp.net-core

I have a task to deploy aspnet core React application to 2 different environments: development and production environments. Each of this environments should be configured separately.
I use Azure devops for CI/CD
AspNet project contains following commands for building application
<Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
<Exec WorkingDirectory="$(SpaRoot)" Command="npm run build" />
I use adal for authorization that is why I have to pass some secret variables that are different for Dev and Prod
const adalConfig = {
tenant: process.env.REACT_APP_TENANT,
clientId: process.env.REACT_APP_CLIENT_ID,
redirectUri: process.env.REACT_APP_REDIRECT_URI,
In Azure devops I set params with command:
echo ##vso[task.setvariable variable=REACT_APP_TENANT;isOutput=true]c00000-00ce-000-0f00-0000000004000
in the azure devops I have next standard commands for aspnet core build app
.Net core installer
Resore
run command (to set env variables)
Build
publish
Issues:
Environment variable is not set.
I even don't know how to build another artefact for production, but not for development.
Maybe you already had task to deploy core react app to 2 different environments? Or please give advice if I need to change deployment strategy at all.
The only solutions what I found is to use .env file but I have to commit this file to git - to deploy it from master. And I still don't know how to use different files for dev and prod.

TLDR;
You have isOutput=true in your task.setvariable command. This only sets a variable in Pipelines engine, to be available to other steps, but doesn't actually map to an env variable. Remove isOutput and you shall see REACT_APP_TENANT env variable.
But only in the following steps - the env variable is not immediately accessible in the same pipeline step.
You can define variables at pipeline level if you know their values upfront - that should simplify things. task.setvariable is more useful for dynamic variables.
If you need different process (or a different set of variables) for different environments, I recommend using multistage YAML pipelines or classic Releases. They both allow for setting up different stages, each with their set of variables.
Long story
We need to distinguish two separate processes:
Deployment pipeline that's executed on CI agent
Web application that may be hosted in many different ways - Azure Web Apps, self hosting, docker/k8s, etc.
Doing echo ##vso[task.setvariable ...] sets the variable in the pipeline (1.).
The place where reading variables takes place (like tenant: process.env.REACT_APP_TENANT) isn't that obvious. If it's nodejs server-side code, it'll be executed in 2. If it's a part of some build script, it'll be read in 1.
React is tricky, because:
It react behaves differently in development and release mode. In Release mode, during the build phase, the whole client-side code is compiled down to a static JS file. So the env variables you set in your pipeline should work.
It cannot simply access any env variable (to protect you from exposing your server env variables on client browser by accident). If using create-react-app (which is what ASP.NET React App does by default), you have to prefix env variables with REACT_APP_ to use them. If using Webpack directly, you'll need some plugin for this.

Related

Use gitlab variable in Terraform module

I work for an enterprise with a number of different gitlab repositories all deploying applications using Terraform. The majority of these code bases uses a standardised module that defines certain tags for resources in our cloud provider. I am wanting to add the Gitlab project id as one of the default tags and while I know how to use pre-defined vars in Terraform by defining an env var starting with TF_VAR, I don't want to have to modify all code bases in order to set it.
What I want to do is set the project id (env var) in the module so that any codebase that consumes this module will automatically have this environment variable set for use in the gitlab pipeline.
Does anyone have any ideas how I might do this?
Thanks,
Adam

One Repository With Multiple Deployments, Environment Variables, and Secrets on Vercel?

I'm doing some early research for a project I plan to deploy to Vercel. I am wondering if the following is possible:
I want to have on GitHub repository. This repository will use environment variables for API tokens, and basic settings.
I have three versions of the project that I want to create. Instead of creating three separate repositories, I'd rather have one repository, and then have the slight differences made using environment variables. This will make updates, fixes, etc much easier.
So, my question is: Is it possible to deploy one repository three times, each with different environment variables, using Vercel?
Yes, possible in deploying multiple environments in 1 repository. This can be done by importing your project to Vercel. For evey commit you made on the git repo, there is a completely new environment created for that. See https://vercel.com/docs/v2/git-integrations
You may also opt to create different git branches for each environment, and Vercel will take care in creating new environment for them. See https://vercel.com/docs/v2/git-integrations/vercel-for-github#a-deployment-for-each-push
With regards to environment variables, here's what the doc says:
The maximum number of Environment Variables per Environment per Project is 100. For example, you can not have more than 100 Production Environment Variables.
Moreover, the total size of Environment Variables applied to a Deployment (including all the Environment Variables Names and Values) is limited to 4kb. Deployments made with Environment Variables exceeding the 4kb limit will fail during the Build Step.
- https://vercel.com/docs/v2/platform/limits?query=environment%20va#environment-variables
Environment Variables: https://vercel.com/docs/v2/build-step#environment-variables
Yes, they give you Production, Preview, and Development environments. Each has their own environment variables you can save via the UI, or you can download the .env via the cli with vercel env pull.
https://vercel.com/docs/build-step#environment-variables
Multiple Vercel projects can be created for the same GitHub repo.
In other words, there is no restriction like only a single Vercel project can be created for the single GitHub repo.
Then, different environment variables can be set for different Vercel projects.
Pushing a commit to the GitHub repo triggers build & deploy of multiple Vercel projects.
Referece: https://github.com/vercel/vercel/discussions/4879#discussioncomment-356114

Unable to change environment variable

I am having trouble changing the publish variable within web.config because it amounts to nothing.
Once I set the variable in web.config to Development, for example, when I launch the application, it still says that the environment variable is Production.
As you can see below, the web.config states that I have set the variable to Development.
I am out of ideas and genuinely unsure whether variables can be set this way anymore.
Looking at your first screenshot, it looks like you are running your application from the command line, probably using dotnet run. In this case, you should note that the web.config is completely ignored.
The web.config is only to configure IIS for when you actually deploy your application on IIS. If you run it in any other way, the web.config is not being used and you will have to configure the environment in a different way.
If you want to run the application from the command line, you can set the environment variable using set:
set ASPNETCORE_ENVIRONMENT=Development
dotnet run
If you use a standard ASP.NET Core template, there should also be a launchSettings.json file which configures the default launch settings. If you specify the environment there, dotnet run will automatically pick it up when you run the application from the application’s root directory.

Set environment variable

I need some environment variables for my project. I placed it in the launchSettings.json as described here. I know it is VS-specific feature but it works fine with dotnet run cli command and it looks good for me. However it doesn't work for dotnet publish command. How should I set environment variables for production? I'd like to place it inside the project without using powershell, docker etc.
The entire purpose of using environment variables is so that they are not part of your project. If you want them to be in your project, then just use appsettings.json. That's what it's for.

JBoss AS 7 deployments - use deployment scanner or console repo?

I've started using AS 7 after a migration and trying to work out whether the hot deployment works the same way as the console method of uploading applications?
If the hot deployment stays in the deployment folder, where do the applications "go" when they are loaded by the console (or the cli?). Which method should I be using in an admin role? What happens if I use both?
If you use hotdeploy your application will stay in "deployments", otherwise if you use cli your application will stay in "data" folder.
You can use hotdeploy or cli deploy both, last deployed is the current.
here the documentation about deploy command:
[standalone#localhost:9999 /] deploy --help SYNOPSIS
deploy (file_path [--name=deployment_name] [--runtime_name=deployment_runtime_name] [--force | --disabled] |
--name=deployment_name)
[--server-groups=group_name (,group_name)* | --all-server-groups]
[--headers={operation_header (;operation_header)*}]
DESCRIPTION
Deploys the application designated by the file_path or enables an already existing
but disabled in the repository deployment designated by the name argument.
If executed w/o arguments, will list all the existing deployments.
ARGUMENTS
file_path - the path to the application to deploy. Required
in case the deployment
doesn't exist in the repository.
The path can be either absolute or relative to the current directory.
--name - the unique name of the deployment. If the file
path argument is specified
the name argument is optional with the file name been the default value.
If the file path argument isn't specified then the command is supposed to
enable an already existing but disabled deployment, and in this case the
name argument is required.
--runtime_name - optional, the runtime name for the deployment.
--force - if the deployment with the specified name
already exists, by default,
deploy will be aborted and the corresponding message will printed.
Switch --force (or -f) will force the replacement of the existing deployment
with the one specified in the command arguments.
--disabled - indicates that the deployment has to be added
to the repository disabled.
--server-groups - comma separated list of server group names the
deploy command should apply to.
Either server-groups or all-server-groups is required in the domain mode.
This argument is not applicable in the standalone mode.
--all-server-groups - indicates that deploy should apply to all the
available server groups.
Either server-groups or all-server-groups is required in domain mode.
This argument is not applicable in the standalone mode.
-l - in case none of the required arguments is
specified the command will
print all of the existing deployments in the repository. The presence of the -l switch
will make the existing deployments printed one deployment per line, instead of
in columns (the default).
--headers - a list of operation headers separated by a
semicolon. For the list of supported
headers, please, refer to the domain management documentation or use tab-completion.
I believe the only way to have a hot deployment is to use the file system deployments, e.g. the deployment scanner. You can get some information about that on the application deployment documentation.
When you deploy through the console or CLI the deployment stays compressed and goes into the content directory. There's not much you can really do with the content of it there though.
For production it's advised to not use the deployment scanner. There are several ways to deploy your application, but the easiest tend to be with the web console, CLI or the maven plug-in. There are Java API's as well or you could write a script to execute CLI commands.