Alex Earl This the current init script used on ci.j.io, and this is the biggest part of the job
It would be awesome if you can improve it according your needs and then I can dynamically provision windows machines on azure

PS: While you are there if you can also update the from zulu to adoptopenjdk it would be even more awesome

How are you currently provisioning the windows agents on ci.j.io, meaning, how would I go about testing my changes in my own Azure account?

We use this plugin. This gist contains the init script and the windows version.
So you if you have access to an azure account, you can manually create a windows VM, but another solution would be to use vagrant with the cloudinit plugin

I created this gist with the updated init script. This will install vsbuildtools for Visual Studio 2019. This includes msbuild and also the Windows SDK for signtool to be able to sign applications and installers. It also switches to the AdoptOpenJDK JRE 11.

I also tried to remove "slave" and replace with "agent" as per Jenkins policy of removing the term "slave" as much as possible.

I tested this script in a Windows 2012 R2 Datacenter edition Virtual Machine and it worked fine. The initial process of doing the init will take about 5 to 10 minutes longer because the VS Build Tools installation. I hope that is OK.

I configured trusted.ci with you init script, and I am now looking for testing it.
I am just wondering if we shouldn't upgrade the windows version from 2012 to 2019

The machine was provisioned but something went wrong, I have to investigate

Haaaaa the jnlpurl is not accessible from windows agents as they are in different cloud account (AWS vs azure) and different private network,... the jnlp url is 'https://trusted.ci.jenkins.io:1443' and this url is designed to be used with ssh gateway

As long as we don't move trusted.ci on azure, we can't really use jnlp connection as the master and agents aren't located in the same place at the moment. while there is some pending work, I have no idea when I'll be able to finish that work.

Another solution could be to install java on a windows server 2019 and use ssh connection.

I will look at the Windows Server 2019 path. It would need to setup authorized_keys and what not, is there an example of that being done for Linux agents so I could see variables and what not?

I'll try to find some time next week to move trusted.ci on azure in a network closer to the agents, so we'll be able to use jnlp connection until then, it would be nice to test your script with windows server 2019, as it has better container support.

R. Tyler Croy Found that you can launch Windows VMs using SSH in the Azure VM Agents Plugin configuration (see https://stackoverflow.com/questions/49281049/how-to-preconfigure-azure-windows-image-with-ssh-to-use-with-jenkins-windows-age for an example). The init script would need to be changed to remove the jnlp download an so forth. I am working on an update to try.

I updated the gist to remove the JNLP setup, with the change to the Azure VM Agents setup to automatically install SSH, I think it should work

https://gist.github.com/slide/cbae5bccb4cd8ea9348714d1e8fec2be

I tried, and it sounds almost ready but not yet :\

—
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 6/17/2019 11:53 AM git

d----- 6/17/2019 11:53 AM vstools

Done Init Script.

1 file(s) copied.
'java' is not recognized as an internal or external command,
operable program or batch file.
—

That's my mistake, I didn't add the java path to the PATH environment variable. I am going to try and setup a simple Jenkins master/agent setup on my Azure account to make sure its working correctly. I'll post an updated gist soon.

I updated the gist and tested it on my own Azure account and it seems to work just fine. Can you give it a shot?

https://gist.github.com/slide/cbae5bccb4cd8ea9348714d1e8fec2be

Failing with 'Tool MSBuild is not installed'

It appears that you try to install msbuild from the Jenkinsfile as defined here

Considering that msbuild is installed during the init script, it's probably better to specify a path

I'll update the Jenkinsfile when I am back from vacation. I have super limited internet connection this week.

Can this be closed out?