This is a timeout, not a set delay so as long as the logs are fine and the expected strings are output, this increase should have no effect.
In cases of very large images such as wps-office:chinese where it takes syft several minutes to generate the SBOM, this increase is necessary. Also when webtops all go through the package updates, the builders may be testing multiple large images simultaneously, also making the 300s timeout rather short.
This timeout is used for 2 things:
Checking Syft logs, waiting for SBOM to be exported
Checking the container log of the newly built image, waiting for Services Doneto ensure successful init
The potential downside is, if an image build is faulty and the container does not successfully init (could be upstream issues or dep issues) we currently time out at 300 seconds and fail the build. It's only 5 minutes wasted. But this proposed PR increases that limit to 15 minutes, so a failed build could waste 15 minutes instead of 5.
This is a timeout, not a set delay so as long as the logs are fine and the expected strings are output, this increase should have no effect. In cases of very large images such as
wps-office:chinese
where it takes syft several minutes to generate the SBOM, this increase is necessary. Also when webtops all go through the package updates, the builders may be testing multiple large images simultaneously, also making the 300s timeout rather short.This timeout is used for 2 things:
Services Done
to ensure successful initThe potential downside is, if an image build is faulty and the container does not successfully init (could be upstream issues or dep issues) we currently time out at 300 seconds and fail the build. It's only 5 minutes wasted. But this proposed PR increases that limit to 15 minutes, so a failed build could waste 15 minutes instead of 5.