[Question]: When is https://vstsagentpackage.azureedge.net/agent? updated after a new agent version has been released`?

[SQLSos]

Describe your question

I'm using this URL https://vstsagentpackage.azureedge.net/agent? to understand when a new version of the agent is available for download in my region or for my customer. Now version 3.246.0 is downloaded when I trigger a update but that version is not available on this page.

Please help med understand when this page will be updated.

/Staffan

Versions

All versions

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Operation system

No response

Version controll system

Azure Devops

Azure DevOps Server Version (if applicable)

No response

[ivanduplenskikh]

@SQLSos, could you consider utilizing the GitHub API as an alternative to directly requesting from the CDN. This approach would allow you to manage agent versions in JSON format.

$Result = Invoke-RestMethod -Method 'GET' -Uri https://api.github.com/repos/Microsoft/azure-pipelines-agent/releases/latest
Invoke-WebRequest -Uri $Result.zipball_url -OutFile './agent.zip'
Expand-Archive -Path './agent.zip' -DestinationPath 'latest-agent'

[SQLSos]

Hi, I used that from the beginning, but it doesn't reflect what is downloaded when you trigger a automatic agent update. Since the role out of a new version of an agent is available as a pre-release it will start to roll out between 6-8 days a bit randomly depending on region and customer. I have tried to build logic around that but with no luck.
Checking the download area was my best hope to know what would actually be installed before triggering an update.
I have strict change management to take into account and I need to know what will be installed when I trigger an update on a production server.
You could argue that I should probably download the agent and run the upgrade offline instead. But I have 700 agents and no installation tool that can handle the roll out in a good way. So triggering an update is my best choice.

[ivanduplenskikh]

@SQLSos , could you please clarify it for me? You don't want to set auto-upgrade checkbox in your organization settings, do you?

But you want to update agent manually or through a script, am I right?

I'd also like to answer your original question: we can't be sure about availability of the latest version of the agent in the Azure CDN during the deployment process.

Additionally, it might be helpful for you to trigger agent updating process using the Azure DevOps API
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops&tabs=yaml%2Cbrowser#how-can-i-trigger-agent-updates-programmatically-for-specific-agent-pool

[SQLSos]

Hi again,

No we don't want to update agents automatically since we have strict change management control procedures. We need to be in control of what version is installed and when.

We are using the API to trigger the update and has put together a powershell script running in a pipeline on a schedule that will update all servers over 2-3 weeks time. Staring with test servers in the first iteration. we wait a week and then production leg 1 and after an additional couple of days production legs 2.

This is to minimize disruption when things are not working in a new version. It was not too long ago that something regarding powershell stopped working with a new release. At that time we had only gotten that version installed on the first leg of our production servers and could easy disable the ones that did not work.

We first used the ttps://api.github.com/repos/Microsoft/azure-pipelines-agent/releases/latest to check if a new agent was available but this was not enough because suddenly a different version was installed when we triggered the update through the API.

We have found that the best solution is to check the download area in the CDN but now that is not working either since the index is not updated with the new version available there.

Please help me understand how I can be sure of what version will be installed when i trigger an update through the API.

[SQLSos]

And no it seems this page is not available at all any more....

"https://vstsagentpackage.azureedge.net/agent"

[SQLSos]

What are you guys doing??????!!!!!

this morning when i triggered a update of one of my agents version 4.248.0 was suddenly installed ??

Why is that ? It does not have the latest flag and it does not have the pre-release flag either in the GitHub repo......

[SQLSos]

Today 4.248.1 has a pre-release label, 3.246.0 has the latest label and 4.248.0 is installed when an update of an agent is triggered. Still very confusing how this works.....

[SQLSos]

Now 3.248.0 has the Latest tag. Good. But 4.248.0 is still installed when i trigger an update. Even though it has not got the pre-release tag. Still confusing.

[ivanduplenskikh]

@SQLSos, the current tagging process does not fully cover our rolling out procedure. It means the latest tag is assigned to the agent version when it is globally available, indicating the completion of our rollout process. Please refer to this link for more details.

Additionally, the rollout process may be confusing due to the presence of two active major versions: v3 (.NET6) and v4 (.NET8).

I can propose to you the Agents API from Azure DevOps API documentation. Refer to this link for more details.
Example:
https://dev.azure.com/{ORG_NAME}/_apis/distributedtask/pools/{DEFAULT_POOL_ID}/agents/{HOSTED_AGENT_ID}?api-version=7.0

This API endpoint returns the most recent agent available for your organization.

[SQLSos]

Thanks for the update.

I have actually used a variant of what you suggested, I tested it last week and now when you suggested this approach I decided it must be the best solution for us right now.

I don't check the API you suggested but instead run a job on a MS hosted agent and use the following to get the agent version in use, it will give the same result as what you suggested.
echo "AgentVersion: $(Agent.Version)"
Then I can publish this as a variable and use in subsequent jobs that I use to trigger the agent update depending on certain criteria's like release date and such.

[ivanduplenskikh]

@SQLSos, may I proceed with closing this issue since we have several options to check agent version for now?