Windows workers boot up takes longer than Linux workers, so the current total retry time to verify that we can send an SSM command, which is 5 minutes is not sufficient, in rare cases.
What was the solution? (How)
Increase the timeout for sending an SSM command on a launched EC2 instance.
What is the impact of this change?
More slack in waiting for the windows worker to be booted, less flakiness
How was this change tested?
hatch run fmt
Pulled the worker agent package and installed this version of test-fixtures, confirmed that the timeout was increase and it successfully waited for the worker to start.
Was this change documented?
no
Is this a breaking change?
no
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
What was the problem/requirement? (What/Why)
Windows workers boot up takes longer than Linux workers, so the current total retry time to verify that we can send an SSM command, which is 5 minutes is not sufficient, in rare cases.
What was the solution? (How)
Increase the timeout for sending an SSM command on a launched EC2 instance.
What is the impact of this change?
More slack in waiting for the windows worker to be booted, less flakiness
How was this change tested?
hatch run fmt
Pulled the worker agent package and installed this version of test-fixtures, confirmed that the timeout was increase and it successfully waited for the worker to start.
Was this change documented?
no
Is this a breaking change?
no
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.