You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current Worker Actions dialog offer three options
Graceful shutdown
Forced shutdown
Pause/unpause
Our system have two special variant actions piggybacking on the graceful shutdown action: Rebooting the machine, and restarting the buildbot worker without a reboot.
Rebooting is done for some of our workers in order to clear the system of processes that might remain hanging after the previous run.
Restarting the buildbot worker is usually used to force an upgrade of the source code and configuration of the buildbot worker, e.g during a major buildbot update.
Others may want to have other actions for their workers.
My suggestion is to allow specification of arbitrary actions handled by one or more callbacks to the worker subclass, some extra actions should always be present, such as "Reboot" and "worker restart".
Related to this, I think there should be one or more possible actions in case of various error conditions in the worker. As an example, if the worker is not able to connect to the manager due to the certificate no longer being valid, or the manager hostname changed, it should be possible to automatically refresh the configuration using special actions, e.g by. initiating a "restart worker" function.
The text was updated successfully, but these errors were encountered:
It is a bit complicated as it involve all the communication layers of buildbot.
You will need to add this custom worker action notion in the UI, in the rest api actions, in the master to worker protocol, and in the worker.
On tricky way to do it might be to have a "force build on worker" functionality, which would use of nextWorker callback to force the worker choice for the build.
And then you implement your very special worker action as a build step.
If you create a special WorkerChoiceParameter, you would then filter the forcescheduler that have one of those parameter configured in and display it as a worker action in the UI
The current Worker Actions dialog offer three options
Our system have two special variant actions piggybacking on the graceful shutdown action: Rebooting the machine, and restarting the buildbot worker without a reboot.
Rebooting is done for some of our workers in order to clear the system of processes that might remain hanging after the previous run.
Restarting the buildbot worker is usually used to force an upgrade of the source code and configuration of the buildbot worker, e.g during a major buildbot update.
Others may want to have other actions for their workers.
My suggestion is to allow specification of arbitrary actions handled by one or more callbacks to the worker subclass, some extra actions should always be present, such as "Reboot" and "worker restart".
Related to this, I think there should be one or more possible actions in case of various error conditions in the worker. As an example, if the worker is not able to connect to the manager due to the certificate no longer being valid, or the manager hostname changed, it should be possible to automatically refresh the configuration using special actions, e.g by. initiating a "restart worker" function.
The text was updated successfully, but these errors were encountered: