The default build template has the CheckInGatedChanges
activity ("Check In Gated Changes") being ran outside of the AgentScope
activity ("Run on Agent").
Is there a reason for this? Or rather, could the CheckInGatedChanges
activity be moved into the end of the AgentScope
flow (end of sequence)?
My guess is that Microsoft does not want the agent itself to check-in the changes, but the controller. I am not sure though as I do not know the inner workings of the controller-agent model they have.
The reason I ask is because I need to have an activity run after the changes are checked-in, and that is currently forcing me to use another instance of the AgentScope activity. I would prefer to just put them all in the first AgentScope activity and not use extra resources.
The current location of CheckInGatedChanges in the template makes sure that if you add extra activities to the template, they are not unexpectedly run after the changes have been committed to the server. Furthermore, it allows parallel agent execution to happen. For example, if you want to parallelize the build to multiple agents for scaling, the checkin would need to occur after all the build agent workflows finish.
Those are the reasons I can think of. I think it is safe, if you know that you don't need a convergent point for checking in your changes, to move the CheckInGatedChanges activity into the AgentScope so that you don't have to spawn another AgentScope to do your custom work. I don't think we restrict the scope of this activity.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With