-
Notifications
You must be signed in to change notification settings - Fork 106
Multibranch Pipeline Branch Scanning Hang #458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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.
3e428ce to
7b7abf5
Compare
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.
|
When this feature will be merged ? we need this fix as we are heavily impacted by scan jobs for gitlab. |
jetersen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to resolve merge conflict?
| if (context == null) { | ||
| jenkins.checkPermission(CredentialsProvider.USE_OWN); | ||
| } else { | ||
| context.checkPermission(CredentialsProvider.USE_OWN); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure these should stay in
please swap images, text don't correspond with them |


Description of Changes
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 theindexingTimeoutconfiguration 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:indexingTimeoutwas set to 0.Submitter Checklist