jenkinsci / last-changes-plugin

https://plugins.jenkins.io/last-changes
https://plugins.jenkins.io/last-changes/
31 stars 31 forks source link

Do not rely on the Job's triggerSCM Settings for SVN #76

Open jcouton opened 4 years ago

jcouton commented 4 years ago

Hello, First, I'd like to thank you for your plugin, it's pretty amazing.

I have an issue with the choice made to recover the SVN Authentification from the Job itself. I can see here that you rely on the scmTigger settings to authentify into SVN.

The problem is that our workflow is not that simple. We're using Jenkinsfile which are stored in a git repo. (Thus the SCM settings of the job are set on git) During the pipeline, we manually checkout the sources from a Subversion repository with supplied Credentials. Then I'm using the LastChanges plugin to review the changes of the svn repo (using the wonderful vcsDir parameter).

You guessed it : Problem creating svn auth provider java.lang.ClassCastException: hudson.plugins.git.GitSCM cannot be cast to hudson.scm.SubversionSCM at com.github.jenkins.lastchanges.LastChangesPublisher.perform(LastChangesPublisher.java:153) at com.github.jenkins.lastchanges.pipeline.LastChangesPublisherScript.doPublish(LastChangesPublisherScript.java:32)

Can you add an optional parameter to specify the creds of the repository in which LastChanges will go check it's stuff and build the ISVNAuthenticationProvider yourself ? If this parameter is not provided, go back to the current behavior.

This could simplify #10, And is quite dimilar to the #25

Thank you for your time

jcouton commented 4 years ago

The parameter could be the whole location bloc from the subversion plugin. locations: [ [credentialsId: pipelineSettings.scm.credentials_id, local: ".", depthOption: 'infinity', ignoreExternalsOption: true, remote: "${pipelineSettings.scm.url}"] ] Then maybe you could "re-use" the same Authentification process ?