Support installing a Windows based teamcity agent

Review Request #1008 — Created Oct. 8, 2021 and submitted

Information

imfreedom/ansible
default

Reviewers

This will only cover what's needed to get a working teamcity agent and install
MSYS2, but what we will not cover in this commit is getting all the necessary
dependencies for building Pidgin in Windows

This commit will also update the README to mention that installing the ansible
collections we depend on is now necessary (this is our first use of ansible
collection in this repo and it makes our life easier since it provides some
handy modules for interacting with Windows)

Ran teamcity_simple_agent.yml playbook against a Windows 10 virtual machine and a containerized teamcity server and I ended up getting all the way until a succesfully registered (but unauthorized) agent

Summary ID
Support installing a Windows based teamcity agent
This will only cover what's needed to get a working teamcity agent and install MSYS2, but what we will not cover in this commit is getting all the necessary dependencies for building Pidgin in Windows This commit will also update the README to mention that installing the ansible collections we depend on is now necessary (this is our first use of ansible collection in this repo and it makes our life easier since it provides some handy modules for interacting with Windows)
d69475aa6c1da1d53d90e4d96b3e5cf8e021cfbf
Description From Last Updated

This is set in the windows task but isn't templated.

grimgrim

I didn't think to ask before.. but does this install under msys, mingw32, or mingw64? Also, I don't see anything …

grimgrim

can you add comments on what these values are because have zero idea what PT5M and PT0S mean :-D

grimgrim

what is this needed for exactly?

grimgrim

Can we split out the python install and pip upgrade to it's own role and have the mercurial role depend …

grimgrim

pypa is just the organization, but we're just downloading from pypi right?

grimgrim

we still need to pip install --upgrade hg-evolve

grimgrim

pypi

grimgrim

Once python is it's own role, lets just install meson from there as well.

grimgrim

looks like you're skipping the gplugin support for other languages? That's fine, I just wanted to make sure that that …

grimgrim

this is the python role

grimgrim

pypi?

grimgrim

pypi?

grimgrim
sorvival
sorvival
  1. 
      
  2. Okay so this is my take on the issue about adding ansible code to get a Windows based TeamCity agent.

    Some things that I want to note:
    - I tried my best not to touch ansible code that does not directly involve the Windows side of things, but in one or two places I thought it best to do so since it may avoid inconsistencies in the long run (e.g. in agent.yml we were configuring the buildAgent.properties file with its contents directly in the task and now I moved the contents into a separate jinja2 file inside the templates directory so that it can be reused by a similar task but for Windows)
    - I'm still thinking if I can improve some of the names for the variables, suggestions are certainly welcome
    - I'm in the process of reinstalling Windows from scratch and launching this playbook against it (I forgot to take a snapshot after a clean installation...) to make sure I haven't inadvertently changed something that makes the ansible code work there but won't in a clean install.

    1. 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.

    2. 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.

  3. 
      
grim
grim
  1. 
      
  2. Overall looks pretty good. But I still want to go through an do another pass in bit.

    One thing though, is that once we get the gtk4 transition done, we'll probably want to stop using msys2 as it'll just complicate things.

    Also meson in msys2 right now fails on the pidgin3 builds because of a path discrepency relating to a python script we run during the build. We haven't spent much time investigating that, but seems like we probably should as this is nearing completetion.

    1. 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?

    2. 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 :)

    3. 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?

  3. This is set in the windows task but isn't templated.

    1. 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?

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

    3. 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 :)

  4. 
      
sorvival
sorvival
  1. 
      
  2. Okay so in my opinion rev2 seems to be in much better shape, I left a good summary of the changes I made in the rev change summary field.

    I think this should work fine, I've tested it a few times in a clean Windows 10 VM and everything worked without issues (besides the annoying bug in win_scheduled_task that prevents it to be idempotent when you use a trigger of type logon and due to that that task is always marked as changed :( )

    I'd be happy if someone can take a look at this the way it is now and give me some feedback.

  3. 
      
grim
  1. 
      
  2. roles/mercurial/tasks/windows.yml (Diff revision 2)
     
     

    I didn't think to ask before.. but does this install under msys, mingw32, or mingw64? Also, I don't see anything in here about the evolve extension. It's not a requirement, but it can make things easier.

    1. 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?

    2. 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...

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

    4. sounds good!

  3. roles/teamcity/tasks/windows.yml (Diff revision 2)
     
     

    can you add comments on what these values are because have zero idea what PT5M and PT0S mean :-D

    1. 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

  4. what is this needed for exactly?

    1. 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.

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

    3. 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).

    4. sounds like a good thing to check out.

  5. 
      
sorvival
sorvival
grim
  1. 
      
  2. roles/mercurial/tasks/windows.yml (Diff revision 4)
     
     

    Can we split out the python install and pip upgrade to it's own role and have the mercurial role depend on it?

  3. roles/mercurial/tasks/windows.yml (Diff revision 4)
     
     

    we still need to pip install --upgrade hg-evolve

  4. roles/meson/tasks/windows.yml (Diff revision 4)
     
     

    Once python is it's own role, lets just install meson from there as well.

  5. 
      
sorvival
grim
  1. 
      
  2. roles/mercurial/tasks/windows.yml (Diff revisions 4 - 5)
     
     

    pypa is just the organization, but we're just downloading from pypi right?

    1. Correct, I fixed it in rev6

  3. roles/meson/tasks/windows.yml (Diff revisions 4 - 5)
     
     
  4. looks like you're skipping the gplugin support for other languages? That's fine, I just wanted to make sure that that was the intent.

    1. 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.

    2. 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 ;)

  5. roles/python/tasks/windows.yml (Diff revision 5)
     
     

    this is the python role

    1. 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).

  6. roles/python/tasks/windows.yml (Diff revision 5)
     
     
  7. roles/python/tasks/windows.yml (Diff revision 5)
     
     
  8. 
      
sorvival
sorvival
grim
  1. Ship It!
  2. Awesome work! Thank you for sticking with this and seeing it land!!

  3. 
      
grim
Review request changed

Status: Closed (submitted)

Loading...