Handle GitException

[jglick]

While playing with a CloudBees CI setup configured as code, I noticed to my alarm that when a sample Git repository was offline, Jenkins startup failed:

SEVERE	jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init
hudson.plugins.git.GitException: Command "git ls-remote -- …" returned status code 128:
stderr: fatal: unable to connect to …: errno=Connection refused
	at PluginClassLoader for git-client//org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2846)
	at PluginClassLoader for git-client//org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2185)
	at PluginClassLoader for git-client//org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2079)
	at PluginClassLoader for git-client//org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2070)
	at PluginClassLoader for git-client//org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteReferences(CliGitAPIImpl.java:3799)
	at PluginClassLoader for git//jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:863)
	at PluginClassLoader for scm-api//jenkins.scm.api.SCMSource.retrieve(SCMSource.java:655)
	at PluginClassLoader for scm-api//jenkins.scm.api.SCMSource.fetch(SCMSource.java:617)
	at PluginClassLoader for cloudbees-workflow-template//com.cloudbees.pipeline.governance.templates.TemplateCatalog.getLatestCatalogRevision(TemplateCatalog.java:806)
	at PluginClassLoader for cloudbees-workflow-template//com.cloudbees.pipeline.governance.templates.TemplateCatalog.getCatalogMetadata(TemplateCatalog.java:625)
	at PluginClassLoader for cloudbees-workflow-template//com.cloudbees.pipeline.governance.templates.TemplateCatalog.updateWithCatalogMetadata(TemplateCatalog.java:178)
	at PluginClassLoader for cloudbees-workflow-template//com.cloudbees.pipeline.governance.templates.GlobalTemplateCatalogConfigurator.configure(GlobalTemplateCatalogConfigurator.java:86)
	at PluginClassLoader for cloudbees-workflow-template//com.cloudbees.pipeline.governance.templates.GlobalTemplateCatalogConfigurator.configure(GlobalTemplateCatalogConfigurator.java:59)
	at PluginClassLoader for cloudbees-workflow-template//com.cloudbees.pipeline.governance.templates.GlobalTemplateCatalogConfigurator.configure(GlobalTemplateCatalogConfigurator.java:21)
	at PluginClassLoader for configuration-as-code//io.jenkins.plugins.casc.ConfigurationAsCode.lambda$configureWith$7(ConfigurationAsCode.java:823)
	at PluginClassLoader for configuration-as-code//io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:773)
	at PluginClassLoader for configuration-as-code//io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:823)
	at PluginClassLoader for configuration-as-code//io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:695)
	at PluginClassLoader for configuration-as-code//io.jenkins.plugins.casc.ConfigurationAsCode.configure(ConfigurationAsCode.java:352)
	at PluginClassLoader for configuration-as-code//io.jenkins.plugins.casc.ConfigurationAsCode.init(ConfigurationAsCode.java:341)

It turns out that there was nothing really wrong in the proprietary plugin: GlobalTemplateCatalogConfigurator.configure was catching an IOException thrown from SCMSource.fetch and proceeding. Unfortunately AbstractGitSCMSource.retrieve was passing along a GitException thrown from a GitClient method as is, without wrapping in a declared exception permitted by the interface in scm-api.

While I could have fixed merely this call site, once I started looking I found that the problem was fairly general in this plugin: in a number of places it is implementing APIs from core or scm-api which permit IOException but throwing this unchecked exception. So I decided to fix the general issue. If desired, this PR could be broken up and fixes to just those methods filed separately, though for legibility I find it helpful to be documenting where GitException is thrown.

Initially developed by manually looking up usages of GitClient methods throwing GitException and checking their call sites, but it proved much easier to use jenkinsci/git-client-plugin#1166 with GitException checked and fix all compiler errors. My general principle is to just keeping adding throws GitException as needed until coming up to an interface defined in a dependency which does not allow it, and at that point wrapping it. Note that a number of places in the plugin already caught GitException, though generally printing an error to a TaskListener and then signaling some sort of failure separately rather than using it as a cause.

[jglick]

(This is a bug not a chore IMO.)

[MarkEWaite]

Thanks!