[JIRA] (JENKINS-57326) Support jgit and jgitapache with Configuration as Code plugin

mark.earl.waite@gmail.com (JIRA)

unread,

May 4, 2019, 9:06:02 AM5/4/19

to jenkinsc...@googlegroups.com

Mark Waite created an issue

Jenkins /

JENKINS-57326

Support jgit and jgitapache with Configuration as Code plugin

Issue Type:	Improvement
Assignee:	Mark Waite
Attachments:	screencapture-home-markwaite-net-jenkins-configureTools-2019-05-04-07_00_50.png
Components:	git-plugin
Created:	2019-05-04 13:05
Environment:	Jenkins 2.164.2 Configuration as code latest release Git plugin 3.10.0
Labels:	jcasc-compatibility
Priority:	Minor
Reporter:	Mark Waite

When I export the configuration as code definition of my Jenkins server that has JGit configured as one of the git implementations, it includes lines like this:

 
                                                                tool:
  git:
    installations:
    - home: "git"
      name: "Default"
    - home: "jgit"
      name: "jgit"
 
                                                            

When I load those lines into configuration as code, it attempts to create a command line implementation of jgit instead of creating the internal implementation of jgit. The result of reloading that configuration looks like this:

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,

May 4, 2019, 9:07:02 AM5/4/19

to jenkinsc...@googlegroups.com

Mark Waite updated an issue

Jenkins /

JENKINS-57326

Support jgit and jgitapache with Configuration as Code plugin

Change By:	Mark Waite

When I export the configuration as code definition of my Jenkins server that has JGit configured as one of the git implementations, it includes lines like this:

{noformat}

tool:
  git:
    installations:
    - home: "git"
      name: "Default"
    - home: "jgit"
      name: "jgit"

{noformat}

When I load those lines into configuration as code, it attempts to create a command line implementation of jgit instead of creating the internal implementation of jgit. The result of reloading that configuration looks like this:

!screencapture-home-markwaite-net-jenkins-configureTools-2019-05-04-07_00_50.png|thumbnail!

Add Comment

mark.earl.waite@gmail.com (JIRA)

unread,

May 4, 2019, 9:08:03 AM5/4/19

to jenkinsc...@googlegroups.com

Mark Waite assigned an issue to Unassigned

Jenkins /

JENKINS-57326

Support jgit and jgitapache with Configuration as Code plugin

Change By:	Mark Waite
Assignee:	Mark Waite

Add Comment

nicolas.deloof@gmail.com (JIRA)

unread,

May 15, 2019, 4:29:01 AM5/15/19

to jenkinsc...@googlegroups.com

Nicolas De Loof commented on

JENKINS-57326

Re: Support jgit and jgitapache with Configuration as Code plugin

This is caused by `GitTool` not being abstract, so that JCasC can't guess there can be other implementation for this "API".

Maybe we can fix this on JCasC at the price of more complexity, or can just refactor git-client to make GitTool and actual API (interface|abstract class) by Jenkins architecture conventions.

Add Comment

nicolas.deloof@gmail.com (JIRA)

unread,

May 15, 2019, 6:26:02 AM5/15/19

to jenkinsc...@googlegroups.com

Nicolas De Loof edited a comment on

JENKINS-57326

Re: Support jgit and jgitapache with Configuration as Code plugin

This is caused by `GitTool` not being abstract, so that JCasC can't guess there can be other implementation for this "API".

see [https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/plugin/src/main/java/io/jenkins/plugins/casc/BaseConfigurator.java#L160]

Maybe we can fix this on JCasC at the price of more complexity, or can just refactor git-client to make GitTool and actual API (interface|abstract class) by Jenkins architecture conventions.

Add Comment

mark.earl.waite@gmail.com (JIRA)

unread,

May 15, 2019, 7:11:01 AM5/15/19

to jenkinsc...@googlegroups.com

Mark Waite commented on

JENKINS-57326

Re: Support jgit and jgitapache with Configuration as Code plugin

Since git client plugin 3.0 already includes the breaking change of a switch from JGit 4.5 to JGit 5.x (with the resulting API breaks inherent in that change), we can certainly consider additional breaking changes in git client 3.0.

How badly will compatibility be damaged for dependent plugins if GitTool becomes abstract?

Would it be better to create AbstractGitTool and leave GitTool as an implementation?

Add Comment

nicolas.deloof@gmail.com (JIRA)

unread,

May 15, 2019, 7:16:02 AM5/15/19

to jenkinsc...@googlegroups.com

Nicolas De Loof commented on

JENKINS-57326

Re: Support jgit and jgitapache with Configuration as Code plugin

JCasC do detect referenced type from other component relying on git-client, which use `GitTool`. afaik They never explicitely invoke constructor on it. So you can make this class abstract, and add an xstream alias so that existing configuration get loaded into some new `CLIGitTool` implementation. This is still a backward incompatible change but with limited impacts