[JENKINS-24141] Pull ChangeLogSet-related logic out of AbstractBuild #2730

abayer · 2017-01-31T00:52:51Z

JENKINS-24141

Make sure implementation is sane.
SCM.buildEnvVars needs to be changed to Run.
~~Port DependencyGraph as well? (questionable whether we want to do this - feedback desired)~~ (spoiler - we don't want to do this, at least not here - this is a major change I don't think should be in this scope)

Changelog

RFE: Generalize the changelog API to support non-AbstractBuild Run Types

Upstream of:

[JENKINS-24141] Implement RunWithSCMMixIn.RunWithSCM workflow-job-plugin#35
- [JENKINS-24141] Switch to using RunWithSCM for getCulprits logic email-ext-plugin#155
[JENKINS-26100] Return a map of SCM-contributed variables workflow-scm-step-plugin#16
[JENKINS-26100] Switch buildEnvVars and others to Run git-plugin#492
[JENKINS-26100] Change buildEnvVars to Run. subversion-plugin#182
[JENKINS-26100] Change buildEnvVars to take Run mercurial-plugin#102

cc @reviewbybees esp @jglick

Need to add tests, but first need to determine if this actually makes sense as I've implemented it.

jglick

Looking basically right so far.

Do you plan to also port DependencyGraph stuff (upstream/downstream, used tangentially by SCM-related code)?

jglick · 2017-01-31T16:22:32Z

core/src/main/java/hudson/model/View.java

@@ -637,7 +639,7 @@ public Calendar getLastChange() {
        }

        @Exported
-        public AbstractProject getProject() {
+        public Job<?,?> getProject() {


Binary-incompatible, I am afraid, so you will need to do something like

@Deprecated public AbstractProject getProject() { return project instanceof AbstractProject ? (AbstractProject) project : null; } @Exported(name="project") public Job<?,?> getProject() { return project; }

jglick · 2017-01-31T16:25:18Z

core/src/main/java/hudson/model/View.java

-                                        modified.add(user);
+                            if (r instanceof RunWithSCM) {
+                                RunWithSCM runWithSCM = (RunWithSCM) r;
+                                for (ChangeLogSet<? extends ChangeLogSet.Entry> c : runWithSCM.getChangeSets()) {


Tip: to minimize diff hunk size for reviewers (and thus reduce chance of merge conflicts, git blame breakage, etc. etc.), you can keep the original indentation without violating code style:

for (Run<?,?> r : runs) { if (canceled()) { return; } if (!(r instanceof RunWithSCM)) { continue; } for (ChangeLogSet.Entry entry : ((RunWithSCM) r).getChangeSet()) { // …rest untouched

Will note for future reference.

jglick · 2017-01-31T16:25:44Z

core/src/main/java/hudson/model/View.java

                                    }
                                }
                            }
                            // TODO consider also adding the user of the UserCause when applicable
                            buildCount++;
                            // TODO this defeats lazy-loading. Should rather do a breadth-first search, as in hudson.plugins.view.dashboard.builds.LatestBuilds
                            // (though currently there is no quick implementation of RunMap.size() ~ idOnDisk.size(), which would be needed for proper progress)
-                            progress((itemCount + 1.0 * buildCount / builds.size()) / (items.size() + 1));
+                            progress((itemCount + 1.0 * buildCount / runs.size()) / (items.size() + 1));


Avoid gratuitous renames to minimize diff hunks.

Mea culpa. =)

jglick · 2017-01-31T16:25:56Z

core/src/main/java/jenkins/scm/RunWithSCM.java

+import java.util.Set;
+
+/**
+ * @since 2.xxx


use FIXME

Wasn't sure what to do there - perfect.

jglick · 2017-01-31T16:27:44Z

core/src/main/java/jenkins/scm/RunWithSCM.java

+
+    @Nonnull List<ChangeLogSet<? extends ChangeLogSet.Entry>> getChangeSets();
+
+    @Nonnull Set<User> getCulprits();


I think this would be better done as a mixin so that we do not need to copy implementations of getCulprits and hasParticipant.

Was wondering about that - I decided to not go that far initially but now I will do so!

But fwiw, getCulprits actually will differ, since AbstractBuild.getCulprits() relies on AbstractBuild.getDependencyChanges(...), which isn't functionality that I think makes sense in WorkflowRun. Especially since the Fingerprinter stuff is allllll about AbstractProject.

Aaaah, that's what you meant by DependencyGraph work. I will see how it goes, then.

jglick · 2017-01-31T16:28:43Z

core/src/main/java/jenkins/scm/RunWithSCM.java

+
+    @Nonnull Set<User> getCulprits();
+
+    @Nonnull Calendar getTimestamp();


Why? This is already defined in Run.

So I could invoke runWithSCM.getTimestamp() without a bunch of awkward casting - but the mixin approach should help there.

jglick · 2017-01-31T16:30:20Z

And of course you will want a matching PR to workflow-job showing how this will be consumed, and probably one to workflow-scm-step showing how we can take advantage of better APIs to, for example, return a Map<String,String> from the checkout step corresponding to SCM variables.

abayer · 2017-01-31T16:54:41Z

@jglick Hadn't looked at the DependencyGraph stuff - I'll do so. And yeah, there'll be a matching PR for workflow-job, but I wanted to make sure the approach here was sane before posting that second PR, and also yeah, had been thinking of doing testing in workflow-scm-step anyway.

Also bumping to a distinct SNAPSHOT version for dependency builds.

abayer · 2017-01-31T17:52:55Z

core/src/main/java/hudson/model/View.java

@@ -114,7 +117,9 @@
 import java.util.logging.Logger;

 import static javax.servlet.http.HttpServletResponse.SC_BAD_REQUEST;
-import static jenkins.model.Jenkins.*;
+import static jenkins.model.Jenkins.checkGoodName;


For whatever reason, the wildcard import was barfing for me. In general, I had weirdness with pre-existing imports/scoping here for reasons I'm not clear on.

abayer · 2017-01-31T18:06:32Z

DependencyGraph work still to come.

Downstream of jenkinsci/jenkins#2730 More work to go, but this is the initial work.

Conflicts: cli/pom.xml core/pom.xml pom.xml test/pom.xml war/pom.xml

abayer · 2017-04-28T20:34:17Z

Added initial DependencyGraph work - I'm wondering what else needs to be tweaked to just care about AbstractProjects, and am not 100% sure this is a good idea in the first place, but hey.

ghost · 2017-05-01T15:43:55Z

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

abayer · 2017-05-01T16:09:01Z

@jglick The changes on 7fe3a4a are the ones I'm most wary of - DependencyGraph is so thoroughly tied to an AbstractProject world that I'm just not sure this is a good idea. So your feedback on that in particular would be hugely appreciated.

abayer · 2017-05-01T17:16:25Z

Yeah, reverting the DependencyGraph change - if anything, we should tackle that one separately, since it is a pretty broad impact change.

This reverts commit 7fe3a4a.

jglick · 2017-05-01T17:34:29Z

core/src/main/java/jenkins/scm/RunWithSCMMixIn.java

+    public interface RunWithSCM<JobT extends Job<JobT, RunT> & Queue.Task,
+            RunT extends Run<JobT, RunT> & RunWithSCM<JobT,RunT> & Queue.Executable> {
+        @Nonnull
+        List<ChangeLogSet<? extends ChangeLogSet.Entry>> getChangeSets();


I was hoping we could take advantage of -source 8 to have all the methods here other than getRunWithSCMMixIn get default implementations, and started prototyping doing this with other mixin classes. Unfortunately it does not seem to work in general (for example for LazyLoadingJob._getRuns()), because apparently a concrete class cannot pick up a default method when the method is defined in an abstract superclass. Thus

public class Demo { public static void main(String[] args) { System.out.println(new C().answer()); } public static abstract class AC { public abstract int x(); } public interface I { default int answer() {return 42;} } public static class C extends AC implements I {} }

fails to compile:

Demo.java:11: error: C is not abstract and does not override abstract method x() in AC public static class C extends AC implements I {} 1 error

However I think it could work here, since the methods you are expecting these Runs to define are not declared in Run. I am still looking for possible uses in ParameterizedJobMixIn & LazyBuildMixIn.

Good times, good times. Lemme know what I should do when you know what I should do. =)

Well the principle seems to work in #2864, though it is messier there since

this was existing code designed to work in -source 7 (or maybe it was even -source 6 at the time, I cannot recall)

a lot of the methods were defined in other types

Here I think it should be cleaner. Delete RunWithSCM, asRun, and getRunWithSCMMixIn, and make RunWithSCMMixIn into an interface, with default on as many methods as possible.

Ok, I'll give it a shot.

Hmmm...we're ok with changing RunWithSCMMixIn from an abstract class to an interface? In #2864, you kept the abstract class/interface split between ParameterizedJobMixIn and ParameterizedJob, which seems saner to me. I'm worrying about breaking compatibility for something out there that we may not know about that implements RunWithSCM currently...

In #2864 I had to maintain that split since it already existed in public APIs. This is fresh code so we can design it more simply.

Ha. I'd forgotten that RunWithSCM was introduced here! d'oh. =)

Ok, so here's what I ended up doing:

Renamed RunWithSCMMixIn to RunWithSCM - if it should actually be RunWithSCMMixin, lemme know and I can fix that.

Made the non-abstract methods from the old RunWithSCMMixin abstract class into default methods.

Got rid of getRunWithSCMMixIn from AbstractBuild.

I did keep RunWithSCM.asRun(), however - the getCulprits() and hasParticipants(User) methods both needed to call Run methods. There may very well be a way to do this right without asRun(), and if so, I wanna know what it is. =)

daniel-beck · 2017-05-04T14:20:50Z

Is this upstream of something?

jglick · 2017-05-04T14:51:53Z

@daniel-beck see PR description.

abayer · 2017-05-04T15:10:05Z

@daniel-beck @jglick In fairness, I added all those links after his comment. =)

abayer · 2017-05-05T18:02:11Z

@jglick Shall I merge or do you want to?

oleg-nenashev · 2017-05-05T18:12:40Z

@abayer I would give @jenkinsci/code-reviewers some time to provide the feedback. 🐝 from me after the quick check. Will merge on Saturday evening if there is no negative feedback.

abayer · 2017-05-05T18:43:47Z

@oleg-nenashev Alrightie!

daniel-beck · 2017-05-05T22:58:12Z

core/src/main/java/hudson/model/AbstractBuild.java

+    public Set<User> calculateCulprits() {
+        Set<User> c = RunWithSCM.super.calculateCulprits();
+
+        AbstractBuild<P,R> p = getPreviousCompletedBuild();


If this implements caching, where does it consider parallel builds that complete out of order?

shrug? It's the same logic as had previously existed for populating AbstractBuild.culprits, just organized differently.

daniel-beck · 2017-05-05T23:04:18Z

core/src/main/java/hudson/model/Job.java

-
+
+    /**
+     * RSS feed for changes in this project.


Should note that @since TODO it was pulled up into job.

oleg-nenashev

On hold till I move comments from downstream PR by @jglick

abayer · 2017-05-08T16:46:03Z

FYI, I'm doing an ATH run with this to see if anything jumps out.

abayer · 2017-05-09T15:15:37Z

Nothing did jump out from the ATH. @oleg-nenashev are we good to go?

oleg-nenashev · 2017-05-09T15:24:00Z

@abayer nope, I have not moved the comments yet though I see several ones are unanswered in the downstream PR

abayer · 2017-05-09T15:47:36Z

@oleg-nenashev Ok, I thought I'd covered all the pertinent ones for this PR.

oleg-nenashev

🐝 I confirm that the important comment from the downstream PR has been addressed here.

@reviewbybees done

jglick · 2017-05-10T21:06:23Z

@abayer BTW I think some @since tags did not get updated here.

@nonnull

Starting with jenkinsci/jenkins#2730, `AbstractBuild.getChangeSet()` is `@NonNull`, so we can remove the `if` to protect against potential NPEs. Errors were: ``` [INFO] --- spotbugs-maven-plugin:3.1.11:check (default-cli) @ email-ext --- [INFO] BugInstance size is 4 [INFO] Error size is 0 [INFO] Total bugs: 4 [ERROR] Un appel de méthode dans hudson.plugins.emailext.EmailRecipientUtils.convertRecipientString(String, EnvVars, int, TaskListener) passe null à un paramètre déclaré @nonnull de hudson.model.User.get(String, boolean, Map) [hudson.plugins.emailext.EmailRecipientUtils] At EmailRecipientUtils.java:[line 82] NP_NONNULL_PARAM_VIOLATION [ERROR] Un appel de méthode dans hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.getByLegacyUserCause(Run) passe null à un paramètre déclaré @nonnull de hudson.model.User.get(String, boolean, Map) [hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities] At RecipientProviderUtilities.java:[line 152] NP_NONNULL_PARAM_VIOLATION [ERROR] Un appel de méthode dans hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.getByUserIdCause(Run) passe null à un paramètre déclaré @nonnull de hudson.model.User.get(String, boolean, Map) [hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities] At RecipientProviderUtilities.java:[line 133] NP_NONNULL_PARAM_VIOLATION [ERROR] Test de nullité redondant sur une valeur non nulle dans hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.getChangeSetAuthors(Collection, RecipientProviderUtilities$IDebug) [hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities] Redundant null check at RecipientProviderUtilities.java:[line 75] RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE [INFO] ```

@nonnull

Starting with jenkinsci/jenkins#2730, `AbstractBuild.getChangeSet()` is `@NonNull`, so we can remove the `if` to protect against potential NPEs. Errors were: ``` [INFO] --- spotbugs-maven-plugin:3.1.11:check (default-cli) @ email-ext --- [INFO] BugInstance size is 4 [INFO] Error size is 0 [INFO] Total bugs: 4 [ERROR] Un appel de méthode dans hudson.plugins.emailext.EmailRecipientUtils.convertRecipientString(String, EnvVars, int, TaskListener) passe null à un paramètre déclaré @nonnull de hudson.model.User.get(String, boolean, Map) [hudson.plugins.emailext.EmailRecipientUtils] At EmailRecipientUtils.java:[line 82] NP_NONNULL_PARAM_VIOLATION [ERROR] Un appel de méthode dans hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.getByLegacyUserCause(Run) passe null à un paramètre déclaré @nonnull de hudson.model.User.get(String, boolean, Map) [hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities] At RecipientProviderUtilities.java:[line 152] NP_NONNULL_PARAM_VIOLATION [ERROR] Un appel de méthode dans hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.getByUserIdCause(Run) passe null à un paramètre déclaré @nonnull de hudson.model.User.get(String, boolean, Map) [hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities] At RecipientProviderUtilities.java:[line 133] NP_NONNULL_PARAM_VIOLATION [ERROR] Test de nullité redondant sur une valeur non nulle dans hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.getChangeSetAuthors(Collection, RecipientProviderUtilities$IDebug) [hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities] Redundant null check at RecipientProviderUtilities.java:[line 75] RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE [INFO] ```

[WIP JENKINS-24141] First work on abstracting out changelogs

bd84482

Need to add tests, but first need to determine if this actually makes sense as I've implemented it.

abayer added the work-in-progress The PR is under active development, not ready to the final review label Jan 31, 2017

jglick self-assigned this Jan 31, 2017

jglick reviewed Jan 31, 2017

View reviewed changes

Switch to a mixin approach

61acefc

Also bumping to a distinct SNAPSHOT version for dependency builds.

abayer commented Jan 31, 2017

View reviewed changes

Minor cleanup, fixing AbstractBuild.getChangeSets()

d7d4a82

abayer added a commit to abayer/workflow-job-plugin that referenced this pull request Jan 31, 2017

[JENKINS-24141] Implement RunWithSCMMixIn.RunWithSCM

5a72cab

Downstream of jenkinsci/jenkins#2730 More work to go, but this is the initial work.

abayer mentioned this pull request Jan 31, 2017

[JENKINS-24141] Implement RunWithSCMMixIn.RunWithSCM jenkinsci/workflow-job-plugin#35

Merged

abayer added 4 commits April 25, 2017 11:15

Merge branch 'master' into jenkins-24141

285e83a

Conflicts: cli/pom.xml core/pom.xml pom.xml test/pom.xml war/pom.xml

Add SCM.buildEnvVars(Run,Map<String,String>)

8ff1dd6

Initial work on DependencyGraph

7fe3a4a

Merge branch 'master' into jenkins-24141

569c990

Conflicts: cli/pom.xml core/pom.xml pom.xml test/pom.xml war/pom.xml

jglick removed their assignment May 1, 2017

jglick self-requested a review May 1, 2017 15:23

abayer added needs-more-reviews Complex change, which would benefit from more eyes and removed work-in-progress The PR is under active development, not ready to the final review labels May 1, 2017

Normalize versioning because that was unneeded

4f3172c

Revert "Initial work on DependencyGraph"

e4b84a2

This reverts commit 7fe3a4a.

abayer mentioned this pull request May 1, 2017

[JENKINS-26100] Switch buildEnvVars and others to Run jenkinsci/git-plugin#492

Merged

jglick reviewed May 1, 2017

View reviewed changes

abayer mentioned this pull request May 1, 2017

[JENKINS-26100] Return a map of SCM-contributed variables jenkinsci/workflow-scm-step-plugin#16

Merged

jglick mentioned this pull request May 1, 2017

Offering default methods on ParameterizedJob #2864

Merged

jglick added ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback and removed needs-more-reviews Complex change, which would benefit from more eyes labels May 3, 2017

abayer mentioned this pull request May 4, 2017

[JENKINS-24141] Switch to using RunWithSCM for getCulprits logic jenkinsci/email-ext-plugin#155

Merged

oleg-nenashev self-assigned this May 5, 2017

jglick mentioned this pull request May 5, 2017

Make all CLI commands compatible with Pipeline where possible #2874

Merged

6 tasks

daniel-beck reviewed May 5, 2017

View reviewed changes

Adding a @SInCE TODO for Job.doRssChangelog

b6e1ae5

oleg-nenashev requested changes May 8, 2017

View reviewed changes

oleg-nenashev added on-hold This pull request depends on another event/release, and it cannot be merged right now and removed ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback labels May 8, 2017

Get rid of superfluous Queue.Task/Executable

914963c

oleg-nenashev approved these changes May 10, 2017

View reviewed changes

abayer merged commit 2f5ca1a into jenkinsci:master May 10, 2017

jetersen mentioned this pull request May 24, 2017

[JENKINS-26100] Change buildEnvVars to take Run jenkinsci/accurev-plugin#55

Merged

jglick mentioned this pull request Aug 15, 2017

Eliminate need for reflection when calling getChangeSets jenkinsci/workflow-support-plugin#41

Merged

jglick mentioned this pull request Jun 12, 2023

Move AbstractBuild/index.jelly to Run/index.jelly #8110

Merged

14 tasks


		@Nonnull List<ChangeLogSet<? extends ChangeLogSet.Entry>> getChangeSets();

		@Nonnull Set<User> getCulprits();


		@Nonnull Set<User> getCulprits();

		@Nonnull Calendar getTimestamp();

[JENKINS-24141] Pull ChangeLogSet-related logic out of AbstractBuild #2730

[JENKINS-24141] Pull ChangeLogSet-related logic out of AbstractBuild #2730

Conversation

abayer commented Jan 31, 2017 • edited by oleg-nenashev Loading

Changelog

jglick 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

jglick commented Jan 31, 2017

abayer commented Jan 31, 2017

Choose a reason for hiding this comment

abayer commented Jan 31, 2017

abayer commented Apr 28, 2017

ghost commented May 1, 2017

abayer commented May 1, 2017

abayer commented May 1, 2017

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

daniel-beck commented May 4, 2017

jglick commented May 4, 2017

abayer commented May 4, 2017

abayer commented May 5, 2017

oleg-nenashev commented May 5, 2017

abayer commented May 5, 2017

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

oleg-nenashev left a comment

Choose a reason for hiding this comment

abayer commented May 8, 2017

abayer commented May 9, 2017

oleg-nenashev commented May 9, 2017

abayer commented May 9, 2017

oleg-nenashev left a comment

Choose a reason for hiding this comment

jglick commented May 10, 2017

abayer commented Jan 31, 2017 •

edited by oleg-nenashev

Loading