Support installing a Windows based teamcity agent

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

sorvival
imfreedom/ansible
default
INFRASTRUCTURE-49
infrastructure
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
Support installing a Windows based teamcity agent
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
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?

  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.

  5. 
      
sorvival
Review request changed

Change Summary:

  • Clarify use of ISO8601 duration representation in win_scheduled_task module
  • Explain why we need to mark the Red Hat publisher certificate as trusted when installing spice guest tools

Commits:

Summary
-
Support installing a Windows based teamcity agent
+
Support installing a Windows based teamcity agent

Diff:

Revision 3 (+1426 -94)

Show changes

Loading...