[JENKINS-48061] Add new "Discover other refs" trait, GitBranchSCMHead and GitRefSCMHead #577

rsandell · 2018-03-15T16:18:58Z

JENKINS-48061 - Add GitBranchSCMHead and GitRefSCMHead

To be able to fetch commits not on any branch or tag

Checklist

I have read the CONTRIBUTING doc
I have referenced the Jira issue related to my changes in one or more commit messages
I have added tests that verify my changes
Unit tests pass locally with my changes
I have added documentation as necessary
No Javadoc warnings were introduced with my changes
No findbugs warnings were introduced with my changes
I have interactively tested my changes
Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

What types of changes does your code introduce? Put an x in the boxes that apply

Bug fix (non-breaking change which fixes an issue)

And migrate old usage of plain SCMHead

rsandell · 2018-03-15T16:28:47Z

SCMHeadMigrationImpl is an internal class in GitBranchSCMHead

MarkEWaite · 2018-03-16T16:03:51Z

@rsandell is this pull request far enough along that I should evaluate it? I'm certainly not as qualified as @stephenc, but I'm willing to code review it if you think my weekend code review will help.

rsandell · 2018-03-16T17:03:25Z

@MarkEWaite any help is good help :)
I believe the basics are there, otoh I just got an idea that might change some things ;) Because all is not working yet and I know I've broken at least one test.

MarkEWaite · 2018-03-16T17:47:02Z

I've been asked to help this weekend with reviewing and improving the Jenkins-X documentation and initial experience. I will place the review of this pull request as second priority behind the Jenkins-X work. They're both open source, and they are competing for my weekend time...

MarkEWaite · 2018-03-17T05:25:02Z

@rsandell while working through the pull request with debugging breakpoints set in the changes, I found a section of code that seemed to be untouched by the existing tests.

Would you consider using 13882c92807ba89ea2dad694f2ec8ac6160e7f10 from my fork as ideas for additional tests? Several items are in a comment which I believe should work but do not work. I may be wrong thinking they should work, but at least the tests provide some additional coverage.

Since it seems like the git protocol doesn't allow discovering unpublished refs anyway, we can do ahead and find the sha among all published refs instead

stephenc

Getting there

stephenc · 2018-03-19T17:03:03Z

src/main/java/jenkins/plugins/git/GitBranchSCMHead.java

@@ -43,6 +42,11 @@ public GitBranchSCMHead(@NonNull String name) {
        super(name);
    }

+    @Override
+    public String getRef() {
+        return "refs/heads/" + getName();


Constants.R_HEADS

stephenc · 2018-03-19T17:03:40Z

src/main/java/jenkins/plugins/git/GitBranchSCMHead.java

+
+    @Override
+    public String getRef() {
+        return "refs/heads/" + getName();


Constants.R_HEADS

rsandell · 2018-03-20T16:26:25Z

I'm fiddling with a test for build storm

rsandell · 2018-03-21T14:21:52Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

+                                              return new GitBranchSCMRevision((GitBranchSCMHead)head, b.getSHA1String());
+                                          }
+                                      }
+                                  } else { //TODO change to something


I'm still a bit unsure what to do here.

This required a newer ish shared libraries plugin in the test scope which required a slightly newer jenkins core

rsandell · 2018-03-23T16:43:10Z

@stephenc I might be done now, still a bit unsure about what I did in the last commit (ac97524), but I figured I needed to do something there :)

stephenc · 2018-03-23T16:54:40Z

I'll try to review on monday... ping me by midday in case i forget ;-)

rsandell · 2018-03-23T17:08:03Z

OK, I've been trying to come up with additional tests to write but haven't found anything yet.

Allow more testing without the distraction of a findbugs warning

MarkEWaite · 2018-03-24T16:27:17Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

                            shortHashMatch);
+                } else if (name.startsWith(Constants.R_HEADS)) {


I believe this is unreachable code. I'm surprised the Java compiler didn't detect this.

Line 804 is the same condition and when that condition is satisfied, the method returns.

See my pull request which proposes to change that to Constants.R_TAGS and extends a test to reach that code.

I haven't yet performed any interactive testing of the code change, just code review and running tests with breakpoints set in a debugger. Several breakpoints in changes were not reached during my session, but I've not yet investigated further.

Yea, this must be a copy paste error :/

MarkEWaite · 2018-03-26T01:08:18Z

src/test/java/jenkins/plugins/git/GitBranchSCMHeadTest.java

+        public void before() throws Throwable {
+            if (!Functions.isWindows() && "testMigrationNoBuildStorm".equals(this.getTestDescription().getMethodName())) {
+                URL res = getClass().getResource("/jenkins/plugins/git/GitBranchSCMHeadTest/testMigrationNoBuildStorm_repositories.zip");
+                final File path = new File("/tmp/JENKINS-48061");


This hardcoded path ("/tmp/JENKINS-48061") embedded in the test creates the same types of problems as the JenkinsRule hardcoded path.

If different users are running Jenkins unit tests on the same Unix based computer, only one of them will be allowed to run this test successfully because other users won't have permission to remove the test directory.

See my pull request for a multi-platform proposal that worked in my simple tests.

Could we add an "after" which removes the directory with the hard coded name?

Yea, I usually don't like this way of doing it, but I couldn't figure out how to have a dynamic path without doing a configuration change and thereby voiding the test.

Would a relative path (tmp/JENKINS-48061), instead of an absolute path (/tmp/JENKINS-48061), be of any help? Just thinking out loud.

An @After like @MarkEWaite suggested would be cool, too.

ideally I'd add a "lock file" that contains a time-stamp and if the time-stamp is less than 5 minutes old then sleep until the "lock-file" is deleted... if more than 5 minutes old, wipe the temp dir.

But there should be some way to template in the path without needing to hardcode

Did we get a solution to this? If not, file a JIRA, leave a TODO comment and we can move on

I added an @After to clean up after itself.

…48061

rsandell · 2018-03-26T11:42:25Z

@MarkEWaite I merged all commits from your pr but the build storm test change into this PR. I need to have a think on how/if I can approve it somehow.

stephenc

Looks not bad... some questions and minor niggles

stephenc · 2018-03-26T15:35:33Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

        GitSCMTelescope telescope = GitSCMTelescope.of(this);
        if (telescope != null) {
            String remote = getRemote();
            StandardUsernameCredentials credentials = getCredentials();
            telescope.validate(remote, credentials);
            return telescope.getRevision(remote, credentials, head);
        }
+        if (head instanceof GitSCMHeadMixin) {
+            context = context.withoutRefSpecs().withRefSpec(((GitSCMHeadMixin) head).getRef());


What about somebody who has added additional ref specs in a trait... will those refspecs be removed now?

Yes I was a bit hesitant on that myself, context.withoutRefSpecs() does clear all refspecs from the traits.
But from what I can tell, in this context you are after a specific SCMHead so wouldn't all other refspecs just be a waste of time and bandwidth?

A comment explaining the logic as to why it is ok to strip it out here would be ideal then

stephenc · 2018-03-26T15:40:08Z

src/main/java/jenkins/plugins/git/GitBranchSCMHead.java

+    }
+
+    @Override
+    public String getRef() {


final let's not let anyone hijack branch for a non-branch

stephenc · 2018-03-26T15:41:18Z

src/main/java/jenkins/plugins/git/GitSCMHeadMixin.java

+     * The ref, e.g. /refs/heads/master
+     * @return the ref
+     */
+    String getRef();


// TODO provide a default implementation once Java 8 baseline

let's not let anyone hijack branch for a non-branch

robinbanbury · 2018-04-04T15:23:03Z

I tried installing the updated plugin directly from the Jenkins build for this PR. I still get the following issue when attempting to load a pipeline shared library from a PR:

> git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* +refs/pull-requests/*/from:refs/remotes/origin/pr/*
> git rev-parse pr/33^{commit} # timeout=10
ERROR: Could not resolve pr/33
hudson.plugins.git.GitException: Command "git rev-parse pr/33^{commit}" returned status code 128:
stdout: pr/33^{commit}

stderr: fatal: ambiguous argument 'pr/33^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1609)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:794)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at jenkins.plugins.git.AbstractGitSCMSource$10.run(AbstractGitSCMSource.java:859)
at jenkins.plugins.git.AbstractGitSCMSource$10.run(AbstractGitSCMSource.java:853)
at jenkins.plugins.git.AbstractGitSCMSource.doRetrieve(AbstractGitSCMSource.java:352)
at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:853)
at jenkins.scm.api.SCMSource.fetch(SCMSource.java:598)
at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.retrieve(SCMSourceRetriever.java:80)
at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:153)
at org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:134)
at org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:125)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1065)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:129)
at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:123)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:517)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:480)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:269)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
ERROR: No version pr/33 found for library forgerock-pipeline-libs
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: Loading libraries failed

1 error

at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:129)
at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:123)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:517)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:480)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:269)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
Finished: FAILURE

I'm using the refspec +refs/pull-requests/*/from:refs/remotes/@{remote}/pr/* in the global pipeline library configuration, then accessing that library in my pipeline like this: @Library('my-pipeline-library@pr/<pull request ID>') - that was broken by version 3.6.4 of the plugin

jacob-keller · 2018-04-13T15:52:08Z

I tried installing the updated plugin directly from the Jenkins build for this PR. I still get the following issue when attempting to load a pipeline shared library from a PR

It looks like an issue that can occur if your shared pipeline doesn't fetch the refs properly, since git is trying to resolve pr/33^{commit} and pr/33 doesn't exist...

Can you run "git rev-parse pr/33^{commit} in the work tree manually and see what happens? What about if you add the "--" after to force git to treat it like a revision (that should at least clarify the error message).

rsandell · 2018-04-17T10:57:58Z

@robincsmith you should not use the additional refspecs trait but instead the new "Discover other refs".

robinbanbury · 2018-04-17T13:15:49Z

Thanks @rsandell - I'll try that, using the latest build

robinbanbury · 2018-04-18T14:20:32Z

@rsandell that looks awesome. To confirm, under the new "Discover other refs" behaviour, I used pull-requests/*/from (Bitbucket Server 5.8.0)

Then, in my pipeline:

@Library('some-pipeline-library@pull-requests/33/from') _

And the correct commit was found.

rsandell · 2018-04-18T15:20:19Z

@robincsmith yes, but with the new trait

@Library('some-pipeline-library@pull-requests-33') _

should also work, and you can change the name mapping behind the advanced button to enable

@Library('some-pipeline-library@pr-33') _

as well.

robinbanbury · 2018-04-18T15:49:39Z

Yep, I confirm those work as well (with the necessary values in the 'advanced' section)

hughsaunders

Works for me checking out libraries from pull requests :D

The methods that had the issues should probably all just be removed since almost all just have the default implementation. But I wanted to disturb existing code as little as possible.

stephenc · 2018-05-02T13:01:30Z

@rsandell So I have not done final code review, one question for yourself and @MarkEWaite

This PR adds a new "Discover other refs" trait...

In my mind, the majority of users probably do not want this. If we have it there then the likelihood is that we will have lots of users using it to try and discover PRs from GitHub... something that the GitHub Branch Source is better at... similarly, we'll have users using this to integrate with Gerrit instead of driving a full Gerrit Branch Source integration, etc

Would it be better to make this trait abstract and move the implementation into a separate extension plugin. This would IMHO save the majority of users from wondering what "Discover other refs" is all about while still enabling the power users who need it (for e.g. shared libraries) to get the feature?

WDYT?

P.S. I don't mind which you opt for, as long as you two agree and document your logic

rsandell · 2018-05-02T13:08:00Z

Putting it in a separate plugin seems a bit excessive to me, though I understand your argument for doing so. Maybe some harsh words in the description/help could suffice? Though what those harsh words would be I don't know :)

stephenc

Hopefully from here on, I can just review the diffs ;-)

Looking good... I'm just being careful given the importance of this plugin

stephenc · 2018-05-02T13:29:47Z

pom.xml

    <java.level>7</java.level>
    <no-test-jar>false</no-test-jar>
    <concurrency>1C</concurrency>
    <findbugs.failOnError>false</findbugs.failOnError>
-    <workflow.version>1.14.2</workflow.version>
+    <!--<workflow.version>1.14.2</workflow.version>-->


rainy day code?

stephenc · 2018-05-02T13:30:54Z

pom.xml

+    <dependency>
+      <groupId>org.jenkins-ci.plugins.workflow</groupId>
+      <artifactId>workflow-step-api</artifactId>
+      <version>2.10</version>


I thought the workflow 2.x series required upgrading code to 2.7+ (fine if it doesn't... but we should confirm)

Nope, workflow 2.x is just the mono repo extraction of all the sub-plugins. All versions that I picked has a max core version of 1.642.3, that's why I bumped core dependency to that.

stephenc · 2018-05-02T13:31:33Z

src/main/java/hudson/plugins/git/browser/AssemblaWeb.java

@@ -14,6 +14,7 @@
 import org.kohsuke.stapler.QueryParameter;
 import org.kohsuke.stapler.StaplerRequest;

+import javax.annotation.Nonnull;


Can we stick to the findbugs ones?

I used whatever annotation that the methods extended does in an effort to try and not make too much of a mess :)

stephenc · 2018-05-02T13:33:00Z

src/main/java/hudson/plugins/git/browser/AssemblaWeb.java

        public String getDisplayName() {
            return "AssemblaWeb";
        }

        @Override
-        public AssemblaWeb newInstance(StaplerRequest req, JSONObject jsonObject) throws FormException {
+        public AssemblaWeb newInstance(StaplerRequest req, @Nonnull JSONObject jsonObject) throws FormException {


these seem like unrelated changes... ideally the core version bump would be in a separate PR... not saying to move it out now... just noting for future code archeologists

Yepp, I kept all those changes in it's own commit so that it can be reverted if it was too much in the PR, but I can't get a green build without it. I consulted with @MarkEWaite on what to do about it :)

The core and plugin bumps is needed for the built storm fix and something else I can't remember at the moment.

stephenc · 2018-05-02T13:37:11Z

src/main/java/jenkins/plugins/git/GitSCMSourceContext.java

@@ -272,6 +317,9 @@ public final C withRemoteName(String remoteName) {
    @NonNull
    public final List<RefSpec> asRefSpecs() {
        List<RefSpec> result = new ArrayList<>(Math.max(refSpecs.size(), 1));
+        if (wantOtherRefs() && wantBranches()) {


what happens if only one of these is true?

Well if it want other refs, then that refspec is already added to the list retrieved below. Which means that if you also want branches that refspec needs to be added, otherwise you will only fetch the other refs and not the branches.

So if we don't want other refs (and no other explicit refspec is set) then the list of refspecs is empty and so the branches will be fetched as by default.

I.e. this is an ugly hack to get it to work when you both want other refs and branches, if any of those are false we can go on with our normal flow. :)

thanks for the clarifying comment

stephenc · 2018-05-02T13:45:19Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

@@ -420,6 +440,7 @@ protected void retrieve(@CheckForNull SCMSourceCriteria criteria,
            if (context.wantTags()) {
                referenceTypes.add(GitSCMTelescope.ReferenceType.TAG);
            }
+            //TODO DiscoverOtherRefsTrait?


rainy day comment? (either delete it or if important but not blocking file a JIRA and update the comment with the JIRA)

this is a comment for you I think, I sprinkled some of those comments around where they might be needed and then implemented in those places I definitely knew they where needed and I knew what to do.
I might have missed removing some that I implemented.

stephenc · 2018-05-02T13:47:24Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

@@ -537,10 +560,84 @@ public Void run(GitClient client, String remoteName) throws IOException, Interru
                    if (context.wantTags()) {
                        discoverTags(repository, walk, request, remoteReferences);
                    }
+                    if (context.wantOtherRefs()) {
+                        discoverOtherRefs(repository, walk, request, remoteReferences,
+                                (Collection<GitSCMSourceContext.WantedOtherRef>)context.getOtherWantedRefs());


WantedOtherRef is not a name I like, especially as it leaks into the public API... any suggested alternatives? (if it is the least bad, well we'll have to live with it)

AdditionalRefSpec or something like that might be better... or worse... suggestions please... and then we pick the least ugly

RefNameMapping aligns better with the usage that gets logged

AdditionalRefSpec is already used in a method somewhere.
The use of wanted was to reflect that it is about the same as wantBranches and wantTags. And I guess my brain got stuck on that train :)

RefNameMapping sounds better, I'll chew on it for a bit.

stephenc · 2018-05-02T13:50:19Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

+        // 1.  A branch name (if we have that we can return quickly)
+        // 2.  A tag name (if we have that we will need to fetch the tag to resolve the tag date)
+        // 3.  A short/full revision hash that is the head revision of a branch (if we have that we can return quickly)
+        // 3.2 A remote refspec for example pull-requests/1/from


just renumber, no sub-numbering

stephenc · 2018-05-02T13:57:35Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

+                    tagName = StringUtils.removeStart(name, Constants.R_TAGS);
+                    context.wantBranches(false);
+                    context.wantTags(true);
+                    context.withoutRefSpecs();
                }


If it is a ref, we save effort by returning the GitRefSCMRevision itself, so we should set a boolean here to say "found a ref match" and then return the GitRefSCMRevision at the end of the loop if the ref match was found. the current code will prefer a tag to a GitRefSCMRevision despite a tag needing date resolution (i.e. more work)

Yes that's the way I designed it after how I interpreted it from our earlier discussions, that it's better if we could return a tag or a branch than a ref.
I guess I misunderstood?

a branch is the best
a ref should be preferred to a tag (because we do not need to resolve the time)

stephenc · 2018-05-02T14:01:28Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

@@ -831,7 +977,7 @@ public SCMRevision run(GitClient client, String remoteName) throws IOException,
                                      }
                                      listener.getLogger()
                                              .printf("Selected match: %s revision %s%n", name, hash);
-                                      return new SCMRevisionImpl(new SCMHead(name), hash);
+                                      return new GitBranchSCMRevision(new GitBranchSCMHead(name), hash);


We are missing the case where the revision does not exist on any branch but does exist in the history of an other ref. Now if that is because client.getBranchesContaining(hash, true) doesn't allow us to query other refs, then we need to file a JIRA, add a comment and move on... otherwise we probably need to revisit the candidatePrefix search to include other refs

Well, the way I think the refspec for the trait is constructed the commits will be fetched as branches on the remote, I don't like it, but it should work. I should probably add a test for that though to verify.

See AbstractGitSCMSourceTest#retrieveRevision_customRef_descendant

that is not on the head of a custom ref

stephenc

just the order of resolution is retrieve(hash) needs fixing

stephenc · 2018-05-04T15:39:15Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

+                                      }
+                                  } else if (head instanceof GitRefSCMHead) {
+                                      try {
+                                          ObjectId objectId = client.revParse(((GitRefSCMHead) head).getRef());


yes covered by the else... i think I was just wondering if we could merge one of the paths... no worries. fine for now

stephenc · 2018-05-04T15:40:20Z

src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java

+                    tagName = StringUtils.removeStart(name, Constants.R_TAGS);
+                    context.wantBranches(false);
+                    context.wantTags(true);
+                    context.withoutRefSpecs();
                }


a branch is the best
a ref should be preferred to a tag (because we do not need to resolve the time)

stephenc · 2018-05-04T15:41:19Z

src/main/java/jenkins/plugins/git/GitSCMSourceContext.java

@@ -272,6 +317,9 @@ public final C withRemoteName(String remoteName) {
    @NonNull
    public final List<RefSpec> asRefSpecs() {
        List<RefSpec> result = new ArrayList<>(Math.max(refSpecs.size(), 1));
+        if (wantOtherRefs() && wantBranches()) {


thanks for the clarifying comment

So we don't have to check timestamps on the tag

stephenc

Probably will need refinement after it hits customers... probably good enough for now

Increment the minor version number because it requires Jenkins 1.642.3 LTS instead of the older 1.625.3 LTS.

rsandell added 2 commits March 9, 2018 17:01

[JENKINS-48061] Introduce GitBranchSCMHead

50e4690

And migrate old usage of plain SCMHead

[JENKINS-48061] Introduce GitRefSCMHead

2eee3e5

MarkEWaite mentioned this pull request Mar 16, 2018

[JENKINS-47870] add support for changelog to arbitrary revision #552

Closed

[JENKINS-48061] GitSCMHeadMixin and discover all published refs

d49fec4

Since it seems like the git protocol doesn't allow discovering unpublished refs anyway, we can do ahead and find the sha among all published refs instead

stephenc reviewed Mar 19, 2018

View reviewed changes

[JENKINS-48061] Use constants not literals

54c5a03

rsandell commented Mar 21, 2018

View reviewed changes

rsandell added 2 commits March 23, 2018 16:05

[JENKINS-48061] Add a test for buildstorm check

5411589

This required a newer ish shared libraries plugin in the test scope which required a slightly newer jenkins core

[JENKINS-48061] Do something when it's a plain ref

ac97524

rsandell changed the title ~~[WiP][JENKINS-48061] Add GitBranchSCMHead and GitRefSCMHead~~ [JENKINS-48061] Add GitBranchSCMHead and GitRefSCMHead Mar 23, 2018

MarkEWaite added 2 commits March 24, 2018 08:38

javadoc warning fix

0a47a2d

Temporary findbugs workaround

474c77e

Allow more testing without the distraction of a findbugs warning

MarkEWaite requested changes Mar 24, 2018

View reviewed changes

Check short name match for tags

919b7bf

MarkEWaite reviewed Mar 26, 2018

View reviewed changes

Merge commit '919b7bf3f194eefa739e68bf27e059abc002cc2a' into JENKINS-…

eb8f378

…48061

stephenc requested changes Mar 26, 2018

View reviewed changes

rsandell added 3 commits March 27, 2018 13:09

[JENKINS-48061] MIT headers and a todo

79a5e1a

[JENKINS-48061] final GitBranchSCMHead.getRef

ceabe36

let's not let anyone hijack branch for a non-branch

[JENKINS-48061] Non GitSCMHeadMixin should be a branch

68a956f

[JENKINS-48061] regrouping and more tests

d686253

MarkEWaite mentioned this pull request Apr 9, 2018

Use Jenkins 2.60.1, JDK 8, and git client 3.0.0 #565

Merged

5 tasks

[JENKINS-48061] Adding DiscoverOtherRefsTrait

75177c4

rsandell added 2 commits April 13, 2018 18:11

[JENKINS-48061] Retrieve other refs

f67a66e

[JENKINS-48061] retrieveRevisions

887ac33

hughsaunders approved these changes Apr 23, 2018

View reviewed changes

Fixing findbugs issues after Jenkins core bump

39f9982

The methods that had the issues should probably all just be removed since almost all just have the default implementation. But I wanted to disturb existing code as little as possible.

rsandell changed the title ~~[JENKINS-48061] Add GitBranchSCMHead and GitRefSCMHead~~ [JENKINS-48061] Add new "Discover other refs" trait, GitBranchSCMHead and GitRefSCMHead May 2, 2018

stephenc requested changes May 2, 2018

View reviewed changes

rsandell added 3 commits May 4, 2018 13:01

[JENKINS-48061] Cleaned up comments and todos

4a7cba8

[JENKINS-48061] rename WantedOtherRefs to RefNameMapping

36a307a

[JENKINS-48061] Added a test to verify we can retrieve a commit

6ffc571

that is not on the head of a custom ref

stephenc requested changes May 4, 2018

View reviewed changes

[JENKINS-48061] Resolve other ref before tag name

191cf55

So we don't have to check timestamps on the tag

stephenc approved these changes May 4, 2018

View reviewed changes

MarkEWaite added 2 commits May 4, 2018 13:29

Use 3.9.0-SNAPSHOT as version

aa84a72

Increment the minor version number because it requires Jenkins 1.642.3 LTS instead of the older 1.625.3 LTS.

Update README maven version reference

0d845c1

MarkEWaite merged commit 927c829 into jenkinsci:master May 4, 2018

kshultzCB mentioned this pull request Jun 6, 2018

Update unit tests for compatibility with git-plugin >=3.9.x jenkinsci/workflow-multibranch-plugin#76

Merged

rsandell deleted the JENKINS-48061 branch January 9, 2019 14:49

MarkEWaite added the bugfix Fixes a bug - used by Release Drafter label Jul 13, 2019

		shortHashMatch);
		} else if (name.startsWith(Constants.R_HEADS)) {

[JENKINS-48061] Add new "Discover other refs" trait, GitBranchSCMHead and GitRefSCMHead #577

[JENKINS-48061] Add new "Discover other refs" trait, GitBranchSCMHead and GitRefSCMHead #577

Conversation

rsandell commented Mar 15, 2018 • edited by MarkEWaite

JENKINS-48061 - Add GitBranchSCMHead and GitRefSCMHead

Checklist

Types of changes

rsandell commented Mar 15, 2018

MarkEWaite commented Mar 16, 2018

rsandell commented Mar 16, 2018

MarkEWaite commented Mar 16, 2018 • edited

MarkEWaite commented Mar 17, 2018

stephenc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsandell commented Mar 20, 2018

Choose a reason for hiding this comment

rsandell commented Mar 23, 2018

stephenc commented Mar 23, 2018

rsandell commented Mar 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsandell commented Mar 26, 2018

stephenc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

robinbanbury commented Apr 4, 2018

jacob-keller commented Apr 13, 2018

rsandell commented Apr 17, 2018

robinbanbury commented Apr 17, 2018

robinbanbury commented Apr 18, 2018 • edited

rsandell commented Apr 18, 2018

robinbanbury commented Apr 18, 2018

hughsaunders left a comment

Choose a reason for hiding this comment

stephenc commented May 2, 2018

rsandell commented May 2, 2018

stephenc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephenc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsandell commented Mar 15, 2018 •

edited by MarkEWaite

MarkEWaite commented Mar 16, 2018 •

edited

robinbanbury commented Apr 18, 2018 •

edited