gitlab-branch-source-plugin icon indicating copy to clipboard operation
gitlab-branch-source-plugin copied to clipboard

[JENKINS-75902] Don't save incomplete pipeline configs on GitLab API errors while fetching project info

Open Pitxyoki opened this issue 4 months ago • 5 comments

Please see JENKINS-75902 for the original issue description.

Several safety assurances are added to the GitLabSCMSource class:

  1. GitLabApiExceptions are allowed to be thrown instead of hidden by IllegalStateExceptions on the getGitlabProject() methods.
  2. The call to getGitlabProject(gitLabApi), at the beginning of the retrieve() method, is enclosed in a dedicated try-catch. This prevents the config.xml from being saved with incomplete data due to any communication error with GitLab. This should avoid the "loss of pipeline triggering" as described in JENKINS-75902.
  3. Other methods (retrieveActions() and createProbe()) that communicate with the GitLab API in a similar way were also changed, but just to throw IOExceptions in a non-breaking way, compatible with their inherited declarations.
  4. Additionally, I add Javadoc to the functions I touched, helping to guide future developers looking at this code.

There are several line changes where only whitespace/indentation is changed. Unfortunately, GitHub highlights the whole lines. You may be able to see the diff more properly in a better diff editor or your IDE, setting it to ignore whitespace changes.

Please note that these changes were the result of some careful investigation on our part (I work for Feedzai) and we think we have headed in the right direction. We would appreciate any guidance if you find something is not right in our reasoning and/or the patch is inappropriate.

This seems to be related to:

Testing done

Testing this involved deploying the patched plugin onto our running Jenkins and leaving it there for one month.

We have not seen the original issue occur again ever since (we have, however, seen a similar occurrence associated to another plugin [cloudbees-folder] — we will open a respective issue+pull request for that as well).

Since we deployed the patched plugin, we have had GitLab become unreachable, but the problem of the pipelines not being triggered (and their config.xml files inconsistent) did not manifest.

Given the complexity of simulating GitLab failures when this plugin communicates with it, I did not implement automated tests. If there is a straightforward way to implement that, I'll appreciate it if you can guide me on how to do it.

Submitter checklist

  • [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • [x] Ensure that the pull request title represents the desired changelog entry
  • [x] Please describe what you did
  • [x] Link to relevant issues in GitHub or Jira
  • [x] Link to relevant pull requests, esp. upstream and downstream changes
  • [x] Ensure you have provided tests that demonstrate the feature works or the issue is fixed

Pitxyoki avatar Jul 17 '25 17:07 Pitxyoki