Closed nathan-objective closed 2 months ago
@jetersen +1 can this be approved and merged?
The breaking change in the GitLab4J API will require lock-step upgrades of the API plugin and its consumers like GitLab branch source plugin. If users upgrade the API plugin without upgrading the consumers (like GitLab branch source), they will see runtime errors. If users upgrade the consumers without upgrading the API plugin, they will see runtime errors.
It would be much better to not have a breaking change in the API. I've proposed to remove the breaking change from the GitLab4J API with pull request:
After more thinking, I believe that the lock-step upgrade is better than the current state where users must choose to not install the most recent release of the GitLab API plugin. When this pull request is merged and released, it will cause the GitLab branch source plugin to require GitLab API plugin 5.6.0-97.v6603a_83f8690 which is a positive step and confirmed working by @nathan-objective .
That doesn't protect users that choose to upgrade GitLab API plugin without upgrading GitLab branch source plugin, but those users can be told to upgrade both plugins, not just the API plugin.
… version of Jenkins
The new version is needed to solve a breaking change in the gitlab4j dependency.
Fixes #435
Testing done
This change was tested by replaying the manual operation that was causing the error, when saving a pipeline and validating that the plugin did not cause the error.
Submitter checklist