Avoid jenkinsapi trying to fetch all jobs. #1045
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By default the jenkinsapi Jenkins class will trigger an eager loading of
all Jenkins jobs via the API. Our Jenkins server buckles under the
weight of this and so we do not want to do this until we need to and
ideally future changes will replace unfiltered polling completely.
There's a malinteraction with the jenkinsapi library and Python
convention which has been causing extremely large HTTP requests whenever
the truthiness of an instance of the Jenkins class is tested.
Jenkins defines a
__len__
method which is used to determinetruthiness. But this method triggers a fetch of every job on our Jenkins
host which can take 2 - 5 minutes to return due to the sheer volume of
jobs.
By avoiding this in favor of an explicit check whether jenkins is an
instance of the JenkinsProxy class we can save taking a really big
runtime hit and cut down on spurious failures due to timeouts.
This is an alternative to #1044 which changes what we're testing since it turns out that there are codepaths in ros_buildfarm that use tri-state logic
JenkinsProxy|None|False
on purpose to distinguish between intentional absence of the Jenkins object and an uninitialized Jenkins object.I'd like to factor away from that or at least make it louder through the use of an explicit class for DontUseJenkins rather than knowing that False and None should be treated differently but this alternative should meet the original needs of #1044 without creating logic errors downstream.