We have a project that we use to update our windows server in a rolling release. Every now and then a server need to be run over the steps more than one time. Is it possible to make a step that send the target back to the previous steps instead of having duplicate steps?
So instead of:
check for update
run updates
reboot
check for update
run updates
reboot
check for update
run updates
reboot
we could have:
check for update
run updates
reboot
check for updates (back to 1 if updates available)
This is an interesting problem, one that we don’t have a clean solution for, unfortunately.
We did come up with a couple of ideas. The first is to have the project set with an auto-deploy trigger that fires when a machine becomes healthy. So you would have the following project
Check for update
Run updates
Reboot if required
Health Check step (to mark the machine as unhealthy).
What would then happen is with the auto-deploy trigger set, when the machine finishes rebooting and comes back online as healthy this project would start again, and keep going until finished. The possible wrinkle here is that this project would run every time a machine restarted (or became healthy) which may or may not be desired behaviour.
The other option would be to split this into a couple of different projects, a “master” project and the project performing the updates. How this would work is the “Master” project which is just a script step that triggers the child project via the API, then looks for an output variable that indicates if a reboot has occurred (or not). It would keep looping until the child project indicated that it had run but not rebooted (i.e. was up to date).
I hope that gives you some ideas, let me know if there is anything else we can help with!
That’s right, you would be using the REST API. The simplest model here would be to run a deployment per target, as while it’s possible to target multiple deployment targets, the looping logic would get more complex.