[Question]: Configure Service

[AiyionPrime]

Describe your question

I'd like to know if and how a configuration servicefile would be possible.

The goal is for the host to configure itself once per boot and configuration change.
The naive approach would be a one-shot service invoking configure.sh once per boot and per configuration change.

config.sh --unattended --url https://myurl --auth pat --token mytoken --pool mypool --agent myagentname --acceptTeeEula

This does work for a new agent, but not for one which was present before.

Something we could do is an unconditional and unevaluated (in order not to fail the one-shot service) config.sh remove prior configuring.

Is there something I can evaluate instead, in order to assess, whether a configure is even necessary or everything is already matching the configured agent?

Versions

v2.259.0 and NixOS 25.11

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Operation system

NixOS

Version controll system

git

Azure DevOps Server Version (if applicable)

No response

[AiyionPrime]

idealy I'd like to see something like validate.sh which exits 0 in case the current configuration matches a configured agent, which is offline.

And non-zero error codes

• if no agent with such a name exists in the pool,
• its online,
• its parameters do not match the local ones.

[sphanley]

Something that might help with what you're describing is that there's a --replace flag you can pass to config.sh, which will cause an agent to replace itself in the case where an agent with the same name was present before, documented here.

I'm not clear what sorts of configuration changes you're wanting to pick up with this, though. Do you mean like picking up new path entries or environment variables? If so, you don't need to fully reregister the agent in the pool. You can rerun env.sh to regenerate those, and the latest values in the .path and .env files will always be read when the agent is (re)started. The only reason I can think of where you'd need to fully deregister and reregister the agent would be if you wanted to change the name it was registered under, move it to a different pool, or similar.