One more thing that I forgot to mention and that I may propose to add to the inventory in some way as variables is that in order for ansible to connect to a Windows machine it needs the following variables set:
ansible_connection: winrm

ansible_become_method: runas

ansible_winrm_server_cert_validation: ignore
In my case, I didn't do a full setup of WinRM (I just used the winrm configuration powershell script provided by ansible) but I think that the best implmentation would probably use credssp as the ansible_winrm_transport and maybe even get a trusted certificate for WinRM to use.

setting those vars in the inventory is probably fine. As for what best way to do the setup is, I hope can figure it out :) Then we can just document that and go from there.

I understand the gtk4 build not requiring MSYS2 (though I definetely do want to see how that would work, probably something you'll in your stream at some point :P), but won't we need to have MSYS installed for a while at least until we officially stop doing Pidgin 2 releases?

pidgin 2 setup is a nightmare and not part of this ansible at all. Basially we download a large tarball, extract it, configure some crap by hand and hope it's fine :)

Oh I see, okay then Pidgin 2 is out of the picture. What about Pidgin 3? Should we keep the installing MSYS tasks from this PR for when we fix the issues for Pidgin 3 or since that may take a bit maybe it's better to keep this PR as simple as possible and remove the tasks that install MSYS for now?

I guess you are referring to the use of {{ ansible_env.TEMP }} in the "download agent files" task of teamcity/tasks/windows.yml? If so, I didn't set the tempDir parameter of the buildAgent properties file to be a variable because I assume that the agent process automatically takes care of cleaning up that directory, which may be a wrong assumption on my end. I also considered that we weren't setting tempDir to something like /tmp/tc in the nix agent installation tasks (see https://keep.imfreedom.org/imfreedom/ansible/file/tip/roles/teamcity/tasks/agent.yml#l48) so I didn't want to have the Windows agent behave differently.
You have more expierince than me with TeamCity, do you think it's worth ensuring that we set tempDir to the users TEMP directory defined in TEMP Windows env var?

I guess my question is just why is teamcity_agent_tmpdir set in teamcity/vars-windows.yml then?

Ohh. Yeah I forgot to remove that variable... at some point I had more than one task that stored files in the user's tmp dir so I created a variable for that but in the end I ended up with a single task so making that a variable was kind of pointless. I'll remove it in the next revision of my PR that I'm currently baking :)

I'm not an expert on this matter by no means so apologize if what I say is stupid. I believe the confusion comes from the fact that when we launch the pacman command we do so from {{ msys_install_path }}\usr\bin\sh.exe" which doesn't make it clear as to whether this will be installed under msys, mingw32 or mingw64. I tried using all 3 .exe and the hg binary seems to be available in all of them (and works), though I don't know if this is an indication of anything...
Evolve doesn't seem to be part of the repositories so we can't just pacman install it. It looks like you are installing mercurial and evolve from the pip repositories, maybe it would be better if we just install pip on mingw32 and mingw64 and install hg and evolve with it?

yeah this gets funky regardless. Honestly might just be easier to install the windows python and then use it's pip to install mercurial and evolve...

Okay I'll give it a try and if it works I'll update the tasks to use mercurial+evolve installed with Windows python.

sounds good!

Sure! TBH I didn't know about this either but appearantly this is part of the ISO8601 standard and is called "duration representation". See https://en.wikipedia.org/wiki/ISO_8601#Durations

The installer for spice guest tools was built using a Red Hat certificate, so we add it to the TrustedPublisher certificate store. Without this, if you were launching the installer using the GUI you'd get a prompt asking you if you trust the publisher that made that installer (Red Hat inc), if you click OK then the certificate gets added to the store I mentioned before. In our case we want to do an unattended install of the spice guest tools, which gets blocked by the aforementioned prompt unless we tell Windows that we trust Red Hat as a publisher beforehand.

so we just drop the cert in the temp directory every ansible run?

Hmm I see your point. Ideally the win_certificate_store module should allow you to use a file from the role instead of only allowing you to use a file already present in the target machine filesystem but that isn't the case. Now that I'm checking, there's a win_certificate_info module that will probably allow us to check that the certificate is installed or not (by its thumbprint) and if it is we just skip the following tasks so the certificate doesn't need to be copied).

sounds like a good thing to check out.

Correct, I fixed it in rev6

Fixed in rev6

Yes, I'm building with meson -Dgplugin:lua=false -Dgplugin:perl5=false -Dgplugin:python3=false -Dconsoleui=false build-win32 (which I think is what is used in the teamcity build configuration for Windows) so I didn't think it made sense to install any lua/perl/python packages besides what are already a dependencies of the base build packages that we require. Maybe we still need those and I just interpreted the build command wrongly, just let me know and we can add the required packages.

We don't need them right now and can always add them later. Right now just getting everything something working is more important than everything ;)

Fixed in rev6 (the comment was meant to be in the mercurial role since that's where that variable is not really defined, so I deleted it from the python role and added it to the mercurial one).

Fixed in rev6

Fixed in rev6