In my organization, we are running several build servers, each with multiple instances of the ADO agent. The servers are set up in this manner (using PowerShell DSC):
1) the agent binaries are downloaded and extracted to a local path on the server, say: C:\Installation\ado-agent
2) for each agent instance defined in the configuration of the server:
the agent binaries are copied once from the path to a dedicated directory for that agent, say: D:\Agents\Build.3 or D:\Agents\Interactive.1
the agent config script is invoked to connect the agent to ADO
After an agent is set up for the first time, its upgrades are managed and performed from ADO (this has various advantages over performing them at server configuration level). Over time, however, binaries in C:\Installation\ado-agent might get updated, so that new agents created on that machine in the future will start from an up-to-date version.
We have a working implementation of the process, but now I'm looking into simplifying it (specifically, step 1) using your package. To fully support my scenario, I would like to implement two optional features, controlled via package parameters:
disable stopping of the services - in my scenario, updates to the agent binaries in the source location on the local disk are not related to updating running instances of the agent, so I don't want the package to interrupt running builds, for instance;
clear the unzip path before unzipping - on occasion, new versions of the agent may no longer contain some files present in an older version, and if those old files remain, the agent may run into issues (I believe this had happened to us once).
In my organization, we are running several build servers, each with multiple instances of the ADO agent. The servers are set up in this manner (using PowerShell DSC): 1) the agent binaries are downloaded and extracted to a local path on the server, say: C:\Installation\ado-agent 2) for each agent instance defined in the configuration of the server:
After an agent is set up for the first time, its upgrades are managed and performed from ADO (this has various advantages over performing them at server configuration level). Over time, however, binaries in C:\Installation\ado-agent might get updated, so that new agents created on that machine in the future will start from an up-to-date version.
We have a working implementation of the process, but now I'm looking into simplifying it (specifically, step 1) using your package. To fully support my scenario, I would like to implement two optional features, controlled via package parameters:
Would you accept a PR with the above changes?