I'm new to Azure Devops. I would like to have devops pipeline environments to be created automatically during pipeline flow. So the 5th line below should create environment if it does not exist:
- deployment: Deploy
displayName: Deploy job
pool:
vmImage: $(vmImageName)
environment: 'production'
Instead I'm getting:
What am I missing?
To automate environment creation I could also use Terraform but this time I cannot find terraform resource config responsible for that.
I had a similar problem and found that the documentation lists some possible reasons for why this can happen:
Quote from learn.microsoft.com:
Q: Why am I getting error "Job XXXX: Environment XXXX could not be
found. The environment does not exist or has not been authorized for
use"?
A: These are some of the possible reasons of the failure:
When you author a YAML pipeline and refer to an environment that does not exist
in the YAML file, Azure Pipelines automatically creates the
environment in some cases:
You use the YAML pipeline creation wizard in the Azure Pipelines web
experience and refer to an environment that hasn't been created yet.
You update the YAML file using the Azure Pipelines web editor and save
the pipeline after adding a reference to an environment that does not
exist.
In the following flows, Azure Pipelines does not have
information about the user creating the environment: you update the
YAML file using another external code editor, add a reference to an
environment that does not exist, and then cause a manual or continuous
integration pipeline to be triggered. In this case, Azure Pipelines
does not know about the user. Previously, we handled this case by
adding all the project contributors to the administrator role of the
environment. Any member of the project could then change these
permissions and prevent others from accessing the environment.
If you are using runtime parameters for creating the environment, it
will fail as these parameters are expanded at run time. Environment
creation happens at compile time, so we have to use variables to
create the environment.
A user with stakeholder access level cannot create the environment as
stakeholders do not access to repository.
In our case, the problem was using runtime parameters for creating the environment.
You have the environment name 'production' hardcoded, so your problem might be related to one of the other cases.
Related
After some internet search, I wasnt able to find a proper way or suggestion on how to access variables from different pipelines. Lets say, from Pipeline A access variables of Pipeline B.
What I did find, is the idea to use Key Vault, which I am not able to use right now. I was wondering if there is a workaround, lets say, with powershell.
All of this is happening in an Azure Devops environment, where I am trying to access/read variables from different pipelines.
Any ideas?
Kind regards
Leo.
You can make use of variable groups to call variables in multiple pipelines within a project.
You just need to reference that variable in the YAML script or release pipeline with the variable group and use it in any pipeline, Refer below :-
I went to my project > Pipelines > Library > Variable Group > And added a variable > You can add multiple variables here storing your secrets or values.
Using the variable group in a yaml pipeline :-
trigger:
- main
pool:
vmImage: ubuntu-latest
variables:
- group: SharedVariables
steps:
- script: |
echo $(databaseserverpassword)
Now, when you run the pipeline, It will ask you to permit the use of variable group for the pipeline.
This will enable access to all the variables in the SharedVariables group.
Output :-
We got our databaseservername value masked.
You can also enable this variable group for all the pipeline in the project by default.
You can use the same variable group in your Classic pipeline or release pipeline in release or specific stages like below :-
Reference :-
Variable groups for Azure Pipelines - Azure Pipelines | Microsoft Learn
For PowerShell - Azure DevOps: how to manage CI/CD variable groups using PowerShell – Radu Narita (ranari.com)
I'm working on my first Azure DevOps Services release pipeline. I've got a secret in a variable group in the Azure DevOps | Library area. I've been struggling with getting to that secret so I can use it in the release pipeline. I see by this article Add & use variable groups on Microsoft's Docs that I must add that in the variables section of the YAML file. However, I've not seen any way to edit the release pipeline YAML file. I can view it, but there appears to be all. If there's a way of editing the YAML file, how do I get to it?
You should be able to do that, earlier To enable YAML release pipeline, you need to activate Multi-stage YAML pipelines in Preview features:
From the Docs,
To help make it even easier to edit and update your pipeline, we’ve
created an in-product editor with IntelliSense smart code completion,
and an easy task assistant
From the documentation you're pointing at.
If you're using YAML pipelines, you can reference the variable group in your YAML pipeline:
variables:
- group: my-variable-group
If you're using the classic mode, you can link the variable group to your pipeline through the UI:
I am currently planning on a type of multi-tenant system, were different resource groups with a set of AppServices are deployed for customers via ARM Templates. Hence, each customer has its own Resource Group and set of AppServices. Currently we use Azure DevOps to deploy to a set of AppServices used for Development and Quality Assurance before it gets to Production. I am now trying to incorporate DevOps into the mix, automating a pipeline creation of some sort... (it would be a copy of an existing pipeline but only changing the Target AppServices). Which is were my question comes from, Is there a way to dynamically create or edit a Release pipeline to add the deployment of those new AppServices, without the need of manually edit or create a pipeline an adding those newly created AppServices, I was thinking something around the lines of being able to copy a yaml file template then replacing the necessary info to point to those AppServices after they have been created, but I am not totally sure where could I store the new yaml file so that it is picked up by Azure DevOps, or how could I would accomplish these, with the main idea being that all of this continues to be part of an automated process (if possible).
Thanks a lot for any help, any suggestion is appreciated.
EDIT:
The question is not about how to Deploy an ARM Template through the DevOps release pipeline (I plan on using a PowerShell Script/REST API to accomplish that), instead, is about when the AppServices Resources are created, I need to deploy code to those newly created AppServices and also update that code when necessary (Hopefully through a Release Pipeline), somehow generate a new release pipeline each time I deploy a new set of Resources. So that, when there is a new update, I could easily have that pipeline triggered and that set if AppServices can be updated (created as part of the automation process "dynamically"). (I Already have a similar pipeline that deploys to a "static" set of AppServices).
This is possible as you eluded to with YAML Pipelines. Based upon the scenario you have subscribed each repository would have it's own pipeline.yml file that will define the trigger, pool etc. It would also reference a repository that will house your yaml template.
The template would accept whichever parameters you may required (resource group, app service name, etc...) The triggering pipeline associated with each repository would pass this information leveraging the teamplate.
By doing this CI/CD can be set up to trigger on the individual pipelines and deploy the appropriate code all while leveraging the same YAML template.
The repository reference would be similar to:
resources:
repositories:
- repository: YAMLTemplates
type: git
name: OrginazationName/YAML Project Name
With the call to the template being similar to:
- template: azure-ARM-template.yml#YAMLTemplate
parameters:
appServiceName: 'AppServiceName'
resourceGroupName: 'ResourceGroupName'
UPDATE
At a high level the YAML pipeline would consist of the following. If all App Services are similar as stated and ARM Templates are similar this how it could be constructed and triggered based on a folder path:
Build necessary artifacts
Publish Pipeline
Deploy Azure Resource Group Task
Deploy App Settings Task (if applicable)
Deploy App Service
Release the deployment pieces for each environment in appropriate stages to help alleviate the amount of copying and pasting each of the above tasks can be part of a template either individually at a task, combination of tasks, or all in one. This would allow for defining the YAML once and referencing it and including app specific components as needed as parameters to the templates.
I'm having trouble setting my appsettings in a deployed docker container on azure.
My setup:
I have a .NET core app
My build pipeline builds a docker image and pushes it to my container registry on azure.
My release pipeline pulls the image based on a tag and deploys it to an azure web app.
I need to deploy the image to multiple environments. Every environment has different appsettings. I defined the variables in my pipeline "variables tab":
And I need to send these to my azure so they can be used.
When I manually add them it works, but i want to extract them from my variables, so I only have to add them once. (see screenshot 1)
Edit: The screenshot above works. But this is not what I'm looking for. As I'd have to edit the appsettings pipeline each time I add or remove a new appsetting. Also I believe that removing an appsetting here will just leave it on the deployed environment.
I'm deploying an existing docker image, so i'm unable to edit the appsetting.json file. I also won't make different docker files for each environment.
Is there a way to achieve this? How can I extract / list the variables defined in my pipeline as docker variables or appsettings?
You can define pipeline variables in your pipeline and have them attached to a specific scope (read stage) or the release scope (applied to all stages).
E.g. I have a variable defined as EnvironmentConnectionString which is defined in two scopes:
Scope Test: "EnvironmentConnectionString = server=test-db; ...."
Scope QA: "EnvironmentConnectionString = server=qa-db;..."
Score Release: "logging_flag=enabled"
Then you can set this up in your "Application and Configuration Settings" like
- ConnectionString $(EnvironmentConnectionString)
- Logging $(logging_flag)
Note the $(variable name) syntax for using these variables
When the different stages of the pipeline run, they automatically pick up the values specific to the stage and apply to azure app settings.
You can have different variable groups for different stages. These Variable Groups should have same variables defined with different values.
For example: The Dev Variable Group and Release group both have variables Port, RequestTimeout... The Port in Dev is 4999 while the Port in Release could be 5000. We can link these groups to specific Stage scope, Dev variable group for Dev stage and Release group for Release stage.
[![enter image description here][1]][1]
Make sure all your stages have same settings like this, and then the variables with be replaced with correspondings values for different scopes.
Update:
Each stage in the pipeline is independent, they represent different environments. So we have to define the settings of stage or settings of the tasks within the stages one by one. We have to define the appsettings input one by one.
[1]: https://i.stack.imgur.com/ukbjs.png
I am constructing a multi-stage Azure Pipeline in Azure DevOps to build and release my product.
I want to use variable groups in this pipeline, so that I can substitute different configuration values for different deployment environments.
I am unable to authorize my variable groups to be used by the pipeline.
When I manually run a build, I see a message on the summary page telling me the variable group is not authorized:
The Azure DevOps documentation says this is to be expected:
When you make changes to the YAML file and add additional resources (assuming that these not authorized for use in all pipelines as explained above), then the build fails with a resource authorization error that is similar to the following: Could not find a {RESOURCE} with name {NAME}. The {RESOURCE} does not exist or has not been authorized for use.
In this case, on the Summary page, you will see an option to authorize the resources on the failed build. If you are a member of the User role for the resource, you can select this option. Once the resources are authorized, you can start a new build.
I am a member of the User role for the variable group, and I am seeing the message, but I am presented with no option to authorize. Is there something else I need to do? Or is there another way I can authorize a specific pipeline to use a variable group?
The provided solution proposed by #hey didn't work for me because i had to use deployment jobs. I've found a hacky way to resolve this error:
Go to your pipeline
Edit
Click on the tree dots > Triggers
Navigate to the variables tab
Variable groups
Add variable groups
Variable groups can only be accessed if they are imported at the "job" level.
Solution:
I have tested and tried to reproduce your issue. In order to solve it, you need to add the variable group under "job".
Explanation / Analysis:
This is how to reproduce and solve the issue:
First, I have tested with the below yaml script, by adding the variable group to the stage (literally at the same level as jobs):
stages:
- stage: build
variables:
- group: 789
jobs:
- job: run_build
pool:
vmImage: 'Ubuntu 16.04'
steps:
- script: echo Build
With this configuration, I was not able to use the variable group. I got the same issue as you:
I then moved the variable group into the job section of the yaml file:
stages:
- stage: build
jobs:
- job: run_build
pool:
vmImage: 'Ubuntu 16.04'
steps:
- script: echo Build
variables:
- group: 789
With the modified configuration, I was able to see and use the Authorize resources option in the error message:
I had this issue as well, but it was because when I created a variable group under Pipelines > Library, the name in Azure Portal did not match the name in my yml file.