jenkinsci / plugin-modernizer-tool

MIT License
4 stars 5 forks source link

Experiment with `jgit`, and keep it up to date #48

Closed gounthar closed 1 week ago

gounthar commented 1 month ago

What feature do you want to see added?

During our last meeting, we discussed the use of jgit. I'd like to propose a few ideas for consideration:

  1. Version Alignment: What if we use the same version of jgit as the one used in either:

  2. Version Discovery: We could utilize updatecli to help us identify the correct version from the Git Client Plugin's pom file.

  3. Dependency Management: We might consider adding the Git Client Plugin's pom as a Bill of Materials (BOM) for better dependency management.

  4. Expert Input: @jonesbusy may have valuable insights or alternative approaches to suggest.

  5. Initial Approach: For now, we could start with a pinned version of jgit. Later, we can explore ways to keep it synchronized with the version used in Git plugins.

What are your thoughts on these suggestions? I'm open to any feedback or alternative ideas.

Upstream changes

No response

Are you interested in contributing this feature?

No response

gounthar commented 1 month ago

You might want to take a look at #49. Please do not merge it, let's discuss it here if you don't mind. Thanks.

jonesbusy commented 1 month ago

At the end does it really matter to have same version than the git-client plugin ?

We will not have any classpath issue

I would just use latest jgit version and keep it up-to-date with dependabot like any other dependency

sridamul commented 1 month ago

I would just use latest jgit version and keep it up-to-date with dependabot like any other dependency

This is what I have been thinking of from the beginning, and I don't understand why do we want to have the same version of jgit as in git-client or git plugin.

gounthar commented 1 month ago

I'd like to clarify the rationale behind using the same jgit version as the git-client plugin:

  1. Proven Reliability:

    • This version is used on thousands of Jenkins controllers.
    • It undergoes thorough testing by Mark before any upgrades.
    • This approach ensures we're using a reliable jgit version without known regressions.
  2. Risk Mitigation:

    • If we were to allow Dependabot to propose the latest available version automatically, we might encounter issues if our tests aren't comprehensive enough.
  3. Balanced Approach:

    • While I see benefits in aligning with the git-client plugin version, I'm open to alternatives.
    • We could define the jgit version manually and then use Dependabot to keep it updated.

I'm interested in hearing your thoughts on this approach and any potential drawbacks or benefits you foresee.