The reason was that I used PSGet to install a PowerShell module (Pester) onto the TeamCity agent server, i.e. I installed it globally.
The downside of this approach was that I didn’t have a great story for knowing whether:
- the module was actually installed on the server
- what version was actually installed
So I decided to investigate how I could overcome these obstacles. This is the result of that “investigation”, enjoy!
I’ve just updated Pester to version 2.0.4 (not yet released on nuget at the time of me writing this post though) via PSGet on the TeamCity server. PSGet knows nothing about versions but I know that the code on GitHub that PSGet will pull down is of version 2.0.4 state.
1. Update Agent Properties
There are a lot built-in requirements that you can use but since this is a custom requirement I decided to implement it like this:
On the TeamCity server go into the agent properties file (C:\TeamCity\buildAgent\conf\ on my server).
I’ve added a parameter at the bottom there:
note: That’s my way of indicating that Pester is now version 2.0.4 on this server (a bit manual but hey?). I think an environment variable is correct since I’ve installed Pester 2.0.4 globally on the server.
Now, the agent will now pick up that change automatically and you can verify it through the agent properties using the TeamCity admin UI:
2. Add the agent requirement
You can even see that you’ll get some “intellisense” for the parameter you just created.
My final requirement will look like this (ensuring that the Pester version will be at least 2.0.4):
Just to try what happens, since the version is actually 2.0.4 now and I don’t have another agent to try on, I will briefly bump up the version requirement to 2.0.5 and see what happens:
The agent becomes incompatible since the requirement is not met and hence I can’t even start the build on this agent…