I've defined Variable Group which downloads secrets from Key Vault.
Looks like that unlike other variables, secrets aren't set automatically as environment variables.
I've tried using a bash script to take those 'task variables' and set them as environment variables but they were gone by the next task:
export ENV1=$(someSecretTaskVariable)
I'm using npm task which can't be provided with environment variables via the UI and the yaml is read only.
How should this be done?
If you want to create an environment variable that is passed to subsequent Azure DevOps tasks, maybe try this :
echo '##vso[task.setvariable variable=ENV1]$(someSecretTaskVariable)'
instead of export ENV1=$(someSecretTaskVariable)
Set variables in scripts
I dont think you can do this via UI, but via yaml you would do this:
- task: xxx
env:
ENV1=$(someSecretTaskVariable)
apparently you can do this:
Unlike a normal variable, they are not automatically decrypted into
environment variables for scripts. You can explicitly map them in,
though.
To pass a secret to a script, use the Environment section of the
scripting task's input variables.
seems like with UI you can only do this with scripting tasks
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=classic%2Cbatch#secret-variables
Related
When you run a pipeline from the Gitlab UI, you are open to add variables to the run:
From the overview of finished pipelines, is there a way to find the set variables and values of specific runs?
As far as I know, these are one time variables you set by running a pipeline manually. You cannot view the the variables in the UI. Instead, like #Origin said you can echo the variable in the job.
example:
script:
- '& echo "$MY_VARIABLE"'
I would recommend you to save your variables in the default CI/CD Settings. (Settings -> CI/CD -> Variables). There you can set, save, protect (from other user roles) and view them for sure. These variables will be used in any pipeline run you do.
i have CI/CD environment in azure devops.i specially want to get the user name who pushed his code to trigger pipeline.i want to use this info as a variable inside the pipeline.do you guys know how can i do that ?
Actually we do have a predefined Build variable .
We can directly use $(Build.RequestedFor) to get the the original user who kick off pipeline
If you want to pass this variable to any other customized variable/parametes.
You could use Logging Commands to set value during your build pipeline. ##vso[task.setvariable variable=testvar The first task can set a variable, and following tasks in the same phase are able to use the variable. The variable is exposed to the following tasks as an environment variable.
Define and modify your variables in a script
To define or modify a variable from a script, use the task.setvariable
logging command. Note that the updated variable value is scoped to the
job being executed, and does not flow across jobs or stages. Variable
names are transformed to uppercase, and the characters "." and " " are
replaced by "_".
For example, Agent.WorkFolder becomes AGENT_WORKFOLDER. On Windows,
you access this as %AGENT_WORKFOLDER% or $env:AGENT_WORKFOLDER. On
Linux and macOS, you use $AGENT_WORKFOLDER.
More details please take a look at this tutorial Define and modify your variables in a script You could also look at this blog: Use Azure DevOps Variables Inline powershell in build and release pipelines
Azure Devops passes that information to pipelines. Check Build.RequestedFor variable: Build variables (DevOps Services), How are the identity variables set?
In Git or TFVC by the Continuous integration (CI) triggers, the
Build.RequestedFor and Build.RequestedForId values are based on the
person who pushed or checked in the changes.
How to use variables you can find here: Define variables
Hi I want to know if I can programatically access my release variables in the powershell release task. My use case is this: I want to create a generic powershell script that can be used to deploy to multiple environments. I want to set an environment variable on the powershell task that will specify env=dev or test or prod, etc. So I want the powershell script to dynamically access the appropriate build variables (without creating a massive switch statement) based on the environment variable. I'm able to access the environment variable just fine.
So I have this:
$deployenv = "${Env:kudu.env}" #(this works just fine)
$apiUrl = '$(dev.kudu.url)' #(when hard coded like this it works fine)
Currently $apiUrl is able to retrieve the release variable just fine but I don't want to hard code "dev" in the param name.
I've tried a bunch of things like
$apiUrl = variables["$deployenv.kudu.url"]
So I'm wondering is that a way to programatically access these release variables from my powershell task?
You're trying to implement a solution to the wrong problem. The actual problem is that you're not using variable scopes properly.
Use the same variable names across your environments and define different values at different scopes. i.e. the DEV environment has a Kudu.Url variable set to the value for the dev environment. The QA environment has a Kudu.Url set to the value for the QA environment. And so on.
I'm creating a VM instance through cloud function in GCE.I want to add some environment variables to the Instance during creation.
I'm referring this code for instance creation:
https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/api/create_instance.py
I don't want to add this in startup script, because already I'm running a set of tasks in startup script, and i want one of those tasks to use these environment variables. Is there any other way,like passing values in config, while creating instance ?
When you create a new Cloud-Function, you can expand the bottom menu named:
Environment variables, networking, timeouts and more
and set your environment variables from there.
Edit: I'd like to specify that environment variables are used by Cloud-Function itself on the main.py. However, you should may be interested into Instance Metadata & Metadata Server.
You can set environment variables by using gcloud command or through GCP Console [1]:
By using gcloud command:
You can use the --set-env-vars flag to define a variable using the gcloud command-line.
e.g.:
gcloud functions deploy FUNCTION_NAME --set-env-vars env1=whatever,env2=whatever FLAGS...
*Note: The --set-env-vars and --env-vars-file flags for environment variables are destructive. That is, they replace all current variables with those provided at deployment. To make additive changes, use the --update-env-vars flag described in the next section.
e.g.:
gcloud functions deploy FUNCTION_NAME --update-env-vars env1=whatever
Through GCP Console:
Open the Functions Overview page in the GCP Console:
GO TO THE CLOUD FUNCTIONS OVERVIEW PAGE.
Click Create function.
Fill in the required fields for your function.
Expand the advanced settings by clicking More.
In the Environment variables section, set variables by clicking Add variable.
References:
[1] https://cloud.google.com/functions/docs/env-var#setting_environment_variables
Essentially, I need a way to inject environment variables for my app since I don't want to check a .env file into my repo. I was hoping to run something like API_URL=api.example.com npm run build, but it looks like you can't prepend things before the task command.
Is there a way to do this or is there a better way to create environment variables for a node app hosted in Azure?
You can add some build variables to the build definition and then reference those in your build steps somewhere. For example, for your API_URL add a build variable with the same name and value. If you need the variable to be secret for any reason (passwords, etc.) just click the lock icon next to the value field.
Then add a new cmd task to your build and move it to the top to set your environment variables before you start your build. The way you reference the build variables is like this...
set API_URL=$(Build.API_URL)
In the UI it will look like this:
I added two cmd tasks to a test build just to show that it is working. The first one is used to set the environment variable and then I used the second to dump all the environment variables so I could see them. You can see in the build logs that it worked.
If you want to reference the build variables using something other than the command line you can find examples of the different ways to reference build variables here. There are also examples of how to use secret variables on that page.
EDIT:
Since you have some concerns about it not being available in your node app I tested it out in the console real quick to show that it will definitely work.
Using yaml config you can switch to script task and then do something like this:
- script: 'npm run'
workingDirectory: 'src'
displayName: 'npm run'
env:
{ API_URL: 'api.example.com' }
tehbeardedone's answer is great for the build machine, and the answer is similar for when running your app in an Azure app service, which I'm thinking is what you really need. This is for if you need your access to these .env files just previous to or after your app has started (post build).
To the Azure portal we go.
Navigate to your app service.
Click "Configuration" under the "Settings" heading.
For each of the variables you'll need during a production run of your app you'll need to:
Click "New application setting"
Paste the name of the variable (exactly as it appears in your .env) into the "Name" field.
Similarly, paste the value of the variable into the next field.
Check the "deployment slot setting" checkbox. As nebulous as this field is, it's necessary. When I didn't do this, the app didn't have access to this variable after running the start command.
Restart your app. If you deployment when well, then your app should have access to the variables add in the manner specified above.