Allow user-defined deployment strategies for multi-replica deployments
What does this MR do?
Allows user-defined deployment strategies.
This allows the user to define a type: RollingUpdate strategy on the runner manager deployment.
Why was this MR needed?
For multi-replica deployments, it is desirable to have the runner manager pods roll a few at a time during deploys to avoid CI jobs getting hung or otherwise losing their connection to the backend. In case of an issue which prevents the new pods from coming up, a few pods on the old deployment will remain running until a minimum number of pods under the new deployment have entered the Ready state, which will allow for automated rollbacks and less downtime for the runners.
What's the best way to test this MR?
Uncomment the new values and run helm upgrade, then run helm upgrade again, or run kubectl rollout restart deployment/gitlab-runner -n <namespace> and observe the difference in the way the pods are rolled out.