-
Notifications
You must be signed in to change notification settings - Fork 869
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question]: When is https://vstsagentpackage.azureedge.net/agent? updated after a new agent version has been released`? #5028
Comments
@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' |
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. |
@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 |
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. |
And no it seems this page is not available at all any more.... |
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...... |
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..... |
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)
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
The text was updated successfully, but these errors were encountered: