Azure-pipelines-agent: Linux/Windows - Provide direct links to download the agent from non-GUI machines

[whytoe]

Please provide direct links for Linux/Windows Agents on the Readme/Documentation. Specifically on the Download/Configure Agent Section

https://www.visualstudio.com/en-us/docs/build/actions/agents/v2-linux.
https://github.com/Microsoft/vsts-agent/blob/master/README.md
https://www.visualstudio.com/en-us/docs/build/actions/agents/v2-windows

Use Cases:
Operating Systems without a Graphical User Interface are unable to see the "Download Agent link"
People shouldnt have to use Chrome/IE F12 Developer tools to track down the binary file for the agents

[bryanmacfarlane]

Instead of having it in the docs (which can tend to go stale), we built it right into the product.

There's a copy to clip board url right in the product which gives the right url.

I don't understand the point about no GUI - the documentation is web based so it's a GUI. Chrome/IE F12 is also a GUI.

What's the scenario here? Do you have a linux or windows cli vis ssh and need to get the agent?

[whytoe]

Yes when using a CLI you need the actual path.
When Copying to clipboard it brings you to a Microsoft Download Forwarder not the actual github download location.

After I have the file, there is no problem installing it.

[whytoe]

This is what is copied to the clipboard https://go.microsoft.com/fwlink/?linkid=851127, so if you are using wget it complicates things because it redirects you to https://github.com/Microsoft/vsts-agent/releases/download/v2.117.2/vsts-agent-ubuntu.14.04-x64-2.117.2.tar.gz

[bryanmacfarlane]

Yes, and that 302s correctly to the actual download. Most cli download tools should follow redirects (wget, curl, etc...). It allows us to (1) patch the version on prem release uses and (2) change where we get binaries (it's github and there's plans to change that but keep release metadata @ github)

You can also use the convenience url: https://github.com/Microsoft/vsts-agent/releases/latest

It goes to latest (119.1) which is fine for 2017 on-prem and beyond. Server keeps back compat. The one server points to for on prem release is just the one that we tested with at the time of the release (and if there's a critical fix we can update the fwlink).

[whytoe]

The filename is saved as https://go.microsoft.com/fwlink/?linkid=851127 instead of vsts-agent-ubuntu.14.04-x64-2.119.1.tar.gz. Don't you think that is a bit confusing for people?

wget https://go.microsoft.com/fwlink/?linkid=851127
--2017-07-09 18:01:39-- https://go.microsoft.com/fwlink/?linkid=851127
Connecting to XXX.XXX.XXX.XXX... connected.
Proxy request sent, awaiting response... 302 Moved Temporarily
Location: https://github.com/Microsoft/vsts-agent/releases/download/v2.117.2/vsts-agent-ubuntu.14.04-x64-2.117.2.tar.gz [following]
--2017-07-09 18:01:39-- https://github.com/Microsoft/vsts-agent/releases/download/v2.117.2/vsts-agent-ubuntu.14.04-x64-2.117.2.tar.gz
Connecting to XXX.XXX.XXX.XXX... connected.
Proxy request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/53052789/5066287c-5cd7-11e7-9783-a7b30ca83abc?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20170709%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170709T220140Z&X-Amz-Expires=300&X-Amz-Signature=ec959ff9cb39a01624124428c7972171f4f63b11bf17d3e346d84ac59564bfff&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dvsts-agent-ubuntu.14.04-x64-2.117.2.tar.gz&response-content-type=application%2Foctet-stream [following]
--2017-07-09 18:01:40-- https://github-production-release-asset-2e65be.s3.amazonaws.com/53052789/5066287c-5cd7-11e7-9783-a7b30ca83abc?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20170709%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170709T220140Z&X-Amz-Expires=300&X-Amz-Signature=ec959ff9cb39a01624124428c7972171f4f63b11bf17d3e346d84ac59564bfff&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dvsts-agent-ubuntu.14.04-x64-2.117.2.tar.gz&response-content-type=application%2Foctet-stream
Connecting to xxx.xxx.xxx.xxx... connected.
Proxy request sent, awaiting response... 200 OK
Length: 72790638 (69M) [application/octet-stream]
Saving to: ‘index.html?linkid=851127’

100%[===================================================================================================================================================================================================>] 72,790,638 1.79MB/s in 36s

2017-07-09 18:02:17 (1.91 MB/s) - ‘index.html?linkid=851127’ saved [72790638/72790638]

[bryanmacfarlane]

No, it's not confusing at all. That's the way http works. It's pretty clear from the output exactly what's going on - it shows it's getting redirected.

This is actually a requirement. The opposite would be a problem. If folks write automation / scripts to download the agent, then their scripts have an url baked into it. If we release a critical update, security update, or move storage then their scripts should still work and not break.

It's also the way MS download center works - the url is a moniker and it redirects to the actually download storage location.

[whytoe]

I do not agree, The actual way to effectly distribute packages to Linux systems is via Package Management.

DotNot Core is doing this appropriately
https://www.microsoft.com/net/core#linuxubuntu