-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-35227] added support for AdditionalCredentials to SubversionSCMSource #189
base: master
Are you sure you want to change the base?
Conversation
issues with externals - moved AddedCredentials to separate file (was nested class before) - issues with ISVNAuthentication and externals in multibranch jobs should be fixed now, when specifying additional credentials
@@ -3238,98 +3254,5 @@ private static StandardCredentials lookupCredentials(Item context, String creden | |||
CredentialsMatchers.withId(credentialsId)); | |||
} | |||
|
|||
public static class AdditionalCredentials extends AbstractDescribableImpl<AdditionalCredentials> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, you must leave this class where it was for reasons of settings compatibility. Nothing is stopping SubversionSCMSource
from reusing it here.
} | ||
|
||
@DataBoundConstructor | ||
@SuppressWarnings("unused") // by stapler | ||
public SubversionSCMSource(String id, String remoteBase) { | ||
public SubversionSCMSource(String id, String remoteBase, List<AdditionalCredentials> additionalCredentials) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this should be in a @DataBoundSetter
only.
public boolean isDeterministic() { | ||
//non-deterministic when using externals, to force Jenkins to recurse into subdirectories | ||
if(usesExternals) { | ||
return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nondeterministic revisions are acceptable only for SCMs which inherently cannot support determinism, like CVS I suppose (though even there -D
timestamps may offer a solution). In the case of Subversion with externals, we would rather need to extend SCMRevisionImpl
to encode the revision number in each external encountered.
@@ -273,7 +294,7 @@ protected SCMRevision retrieve(@NonNull SCMHead head, @NonNull TaskListener list | |||
String repoPath = SubversionSCM.DescriptorImpl.getRelativePath(repoURL, repository.getRepository()); | |||
String path = SVNPathUtil.append(repoPath, head.getName()); | |||
SVNRepositoryView.NodeEntry svnEntry = repository.getNode(path, -1); | |||
return new SCMRevisionImpl(head, svnEntry.getRevision()); | |||
return new SCMRevisionImpl(head, svnEntry.getRevision(), (additionalCredentials.size()>0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not precise. Additional credentials might have been specified but not actually used. More plausibly, the server may use externals which simply do not need any distinct credentials.
@jglick thank you for your input. I've moved AdditionalCredentials back in place. Regarding the non-deterministic revision, it was an easy solution (or workaround) for Jenkins not detecting changes in externals. Of course, the clean solution would be to extend SCMRevisionImpl. But to me it seems that it requires quite a lot of effort to get that done. Would it be okay to have a checkbox in the config and let the user specify whether isDeterministic() should return true or false? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR introduces a breaking change + additionalCredentials handling seems to be error-prone and redundant in some cases.
I would also expect to see a test suite for the change
@@ -297,7 +297,7 @@ public SubversionSCM(List<ModuleLocation> locations, | |||
*/ | |||
public SubversionSCM(List<ModuleLocation> locations, | |||
boolean useUpdate, SubversionRepositoryBrowser browser, String excludedRegions, String excludedUsers, String excludedRevprop, String excludedCommitMessages) { | |||
this(locations, useUpdate, false, browser, excludedRegions, excludedUsers, excludedRevprop, excludedCommitMessages); | |||
this(locations, useUpdate, false, browser, excludedRegions, excludedUsers, excludedRevprop, excludedCommitMessages); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May cause merge conflicts without a reason
@@ -121,6 +122,8 @@ | |||
private final String remoteBase; | |||
|
|||
private String credentialsId = ""; // TODO null would be a better default, but need to check null safety on usages | |||
|
|||
private List<AdditionalCredentials> additionalCredentials; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from what I see it still may be null when you read data from the disk
} | ||
//without getter jelly will crash | ||
public List<AdditionalCredentials> getAdditionalCredentials() { | ||
return(additionalCredentials); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FindBugs will grumble about exposing external implementation. Either make it @Restricted
for Jelly only or wrap with unmodifyableList
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your comments. How do I make it restricted? Does adding "@restricted(NoExternalUse.class)" work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
|
||
public SCMRevisionImpl(SCMHead head, long revision) { | ||
public SCMRevisionImpl(SCMHead head, long revision, boolean usesExternals) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Breaking change, the class was public
/** | ||
* Convenience constructor, especially during testing. | ||
*/ | ||
public SubversionSCM(String[] svnUrls, String[] credentialIds, String[] locals, List<AdditionalCredentials> additionalCredentials) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not believe new methods are really required if you implement proper null handling in the original constructors. You say these methods are useful for testing, but there is no autotests
@@ -136,15 +139,18 @@ public SubversionSCMSource(String id, String remoteBase, String credentialsId, S | |||
setCredentialsId(credentialsId); | |||
setIncludes(StringUtils.defaultIfEmpty(includes, DescriptorImpl.DEFAULT_INCLUDES)); | |||
setExcludes(StringUtils.defaultIfEmpty(excludes, DescriptorImpl.DEFAULT_EXCLUDES)); | |||
this.additionalCredentials = new ArrayList<AdditionalCredentials>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage of this collection is ineffective if you do not plan to modify it on the flight. Use Collections.emptyList()
instead in the code
Would it help to remove the changes to SCMRevisionImpl and isDeterministic() from this PR to get it accepted? Then this PR would only cover AdditionalCredentials for SubversionSCMSource, i.e. for multibranch pipeline jobs, which would solve JENKINS-35227. The reason why I changed SCMRevisionImpl is, because "Scan multibranch pipeline" is not working properly with externals. But as far as I see it, there is no JIRA issue for that problem yet. So maybe I should create an issue for that first. |
+1. An issue would be useful. The scope of this change is not that big, so probably we could have two fixes in a single PR |
Separate pull requests would be better though |
regarding non-deterministic revision
Okay, this PR is now only about additional credentials. Is it good enough to be accepted? |
if(additionalCredentials==null) { | ||
return Collections.emptyList(); | ||
} | ||
return(additionalCredentials); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be better to just return Collections.unmodifyableList(additionalCredentials)
Yes, it looks much better now. I probably could live even without tests for it. @jglick WDYT? |
Any news on this issue? |
Any news on this issue? This fix would help me. |
Still would benefit from tests. Probably ought to be migrated to traits in a newer |
When this will be released? |
This fixes issues with multibranch pipeline jobs and SVN externals. The main problem was that SubversionSCMSource did not allow to configure additional credentials, which caused "svn: E200015: ISVNAuthentication" errors. This patch fixes that. The second problem was that during "Scan Multibranch Pipeline" it was just checked whether the revision number of the SVN root directory changed. Thus it did not detect changes in externals. That was fixed by declaring revision number non-deterministic in SCMRevisionImpl, if additional credentials are configured. Then, Jenkins polls for changes in the whole repository.
This should fix JENKINS-35227 and JENKINS-32167. I am not able to post a comment in the bug reports, because I failed to create an account on jenkins.io.