A quick an easy way to authenticate on Azure management API is to use az cli get-access-token command and use this as a Bearer token on your API calls.
Given that you want to access https://management.azure.com/subscriptions/api you can use:
$token = az account get-access-token | ConvertFrom-Json
You can then get the access token with $token.accesstoken
Finally you can use this token as a Bearer token on your API calls
$headers = @{ Authorization = "Bearer $token.accesstoken" }
Given that you have a blob storage container with multiple files, you could download the most latest one easily with az cli
In my scenario I have a container named backups which includes multiple MS SQL backups. I wanted to download the latest in order to restore through a pipeline on SQL server.
In order to accomplish that you should first login with az cli.
az login
If this is not possible through automation you would have to create a managed identity for your resource. The code is uploaded on the below gist.
You should replace your connection string by getting yours under access keys.
If you remove descending date the default value would be Ascending.
By executing the script you will get a json output like the below:
Recently I faced an issue with my Azure DevOps self hosted container agents. They could not checkout the git repositories and the build stopped due to the default timeout of 60 minutes per run.
This happened for multiple builds, as a result I had to investigate the reason behind this error.
By checking the logs inside the container on the C:\agent\_diag folder I could recognize an error message like the below:
A session for this agent already exists.
Agent connect error: The task agent xxx already has an active session for owner xxx.. Retrying until reconnected.
By searching online, I figured out that this is a reported bug on previous agents versions. In order to resolve, I updated and reconfigured the agent. You can update the agent, either from the GUI or by creating a new container and installing the latest version of azure devops agent.
In order to reconfigure the agent I first took an interactive shell on it.
docker exec -it agent-name powershell.exe
Then inside C:\agent run the below commands.
Reconfigure the agent
This is a temporary fix for your agent. If the problem persists you should open a support ticket on Microsoft to troubleshoot the issue.
When you need to scale up your infrastructure, you should enable as much automated options for maintenance as possible. One of the available options for devops agents are included under Organization Settings -> Agent pools -> Settings.
There you can define automated procedures for cleanup on your agent pools.
In my setup, I changed the days to keep unused working directories to 20.
The working directories of the agent are some folders with specific numbers inside C:\agent\work.
Every time a new build is initiated a new folder for this specific run is created. If the same pipeline runs more than one time, then the same working directory will be kept and the files will get overridden. For example lets say my pipeline A is bind to the folder 5. Then every time the pipeline A runs, then the folder 5 will be used for the sources (git repositories) builds, artifacts etc. All previous data hosted there will be deleted and written again.
The maintenance jobs will remove any directories than are not used for x period of days. In my example I had set up 20 days for that task.
You can configure agent pools to periodically clean up stale working directories and repositories. This should reduce the potential for the agents to run out of disk space. Maintenance jobs are configured at the project collection or organization level in agent pool settings.
You can check your history under Organization Settings -> Agent pools -> Maintenance History.
You can also download the log and figure out how much data have been deleted.
Maintenance jobs:
Create and manage agent pools – Azure Pipelines | Microsoft Docs
Video tutorial on YouTube:
