Multibranch Pipeline Branch Scanning Hang (adopted) - #749
Conversation
This commit removes a unit test that relied on Mockito to mock static methods inside a separate thread. Mockito encounters issues when mocks are accessed across different threads, leading to inconsistent behavior and null values in asynchronous contexts. The test was causing failures due to these limitations, as static mocks were not reliably available within the ExecutorService thread. A potential solution could involve restructuring the code to allow synchronous execution in a single-threaded context for testing purposes, or exploring alternative approaches for mocking in multi-threaded scenarios. Further investigation into better testing strategies for this case is recommended.
This commit removes a unit test that relied on Mockito to mock static methods inside a separate thread. Mockito encounters issues when mocks are accessed across different threads, leading to inconsistent behavior and null values in asynchronous contexts. The test was causing failures due to these limitations, as static mocks were not reliably available within the ExecutorService thread. A potential solution could involve restructuring the code to allow synchronous execution in a single-threaded context for testing purposes, or exploring alternative approaches for mocking in multi-threaded scenarios. Further investigation into better testing strategies for this case is recommended.
| } | ||
|
|
||
| @Test | ||
| public void retrieveMRWithEmptyProjectSettings() throws GitLabApiException, IOException, InterruptedException { |
There was a problem hiding this comment.
Any reason to remove this whole test?
There was a problem hiding this comment.
The original author ran into issues with Mockito and multithreading (see commit message). If you think it's an issue I can try and follow up on this.
There was a problem hiding this comment.
Went at it anyway, managed to fix the issues the original author had.
There was a problem hiding this comment.
@jetersen It's been a while, I'd appreciate it if you could take a look when you have the time, thank you!
|
Hello! Is there an estimation for when these changes will be applied? The issue still happens for Jenkins v2.568.1 and gitlab-branch-source:740.v04f287f9194d and we are forced to restart the Jenkins instance each time we have a hanging scan. Thank you! |
3 participants
Description of Changes
Picking up work from @arechavarria in #458 that's become stale to address #270. Rebased to pick up latest changes and addressed comments in original PR. Also fixed an authentication context regression probably caused by one of the required plugin upgrades post-rebase.
This pull request introduces a configurable
indexingTimeoutparameter to thegitlab-branch-sourceplugin in Jenkins, enabling users to set a maximum wait time in seconds for indexing GitLab repositories. This timeout is applied in two key methods:retrieve(SCMHead head, TaskListener listener): Updated to use anExecutorServiceandFuture, allowing the operation to be cancelled if it exceeds the specified timeout.retrieveActions(SCMSourceCriteria criteria, SCMHeadObserver observer, SCMHeadEvent<?> event, TaskListener listener): Modified to respect the indexingTimeout configuration across the indexing process, including checks on branches, merge requests, and tags.Additionally, a new
indexingTimeoutproperty has been added to the UI configuration in theconfig-detail.jellyfile, enabling users to set the timeout through Jenkins' interface.Testing done
Manual tests were conducted to validate
indexingTimeoutfunctionality in various scenarios:Defined Timeout (greater than 0): A sample timeout was set, and it was verified that the operation would be interrupted if it exceeded the specified time.
Undefined Timeout (0): Confirmed that the operation continued without interruption when
indexingTimeoutwas set to 0.Regression: Tested across different projects and merge requests to ensure the new functionality did not interfere with standard GitLab indexing.
Submitter checklist