Skip to content
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-40979 add trigger cause messages #996

Merged
merged 19 commits into from
Apr 27, 2017
Merged

JENKINS-40979 add trigger cause messages #996

merged 19 commits into from
Apr 27, 2017

Conversation

i386
Copy link
Contributor

@i386 i386 commented Apr 23, 2017

Description

  • Adds trigger cause to Run detail
  • If there are no commits the cause is displayed in Activity and Branch message column

See JENKINS-40979.

screencapture-localhost-8080-jenkins-blue-organizations-jenkins-dropspace-2fwhimsy-activity-1492914891859
screencapture-localhost-8080-jenkins-blue-organizations-jenkins-dropspace-2fwhimsy-detail-master-30-pipeline-1492914875751
screencapture-localhost-8080-jenkins-blue-organizations-jenkins-dropspace-2fwhimsy-branches-1492914866490

Submitter checklist

  • Link to JIRA ticket in description, if appropriate.
  • Change is code complete and matches issue description
  • Appropriate unit or acceptance tests or explanation to why this change has no tests
  • Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.
  • Ran Acceptance Test Harness against PR changes.

Reviewer checklist

  • Run the changes and verified the change matches the issue description
  • Reviewed the code
  • Verified that the appropriate tests have been written or valid explanation given

@vivek there are some Java API changes to help make this happen.

…riggered

* Adds trigger cause to Run detail
* If there are no commits the cause is displayed in Activity and Branch message column
@i386 i386 requested review from vivek and cliffmeyers April 23, 2017 02:37
@@ -25,7 +28,7 @@ public TreePruner accept(Object node, Property prop) {

// for merge properties, the current restrictions on the property names should
// still apply to the child TreePruner
if (prop.merge)
if (prop.merge && child != null)
Copy link
Contributor Author

@i386 i386 Apr 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vivek Use of merge in the 'Cause' @Exported(name="cause", merge = true) caused this NPE. This check fixes it but perhaps this should go upstream?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, please open a PR in stapler with this fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@i386
Copy link
Contributor Author

i386 commented Apr 23, 2017

@michaelneale this is going to make it 1,000,000 times easier to find the correct runs of the ATH.

@@ -158,6 +160,9 @@ public Object getValue(Property property, Object model, ExportConfig config) thr
printError(model.getClass(), e);
return SKIP;
}
} else if (model instanceof Item || model instanceof Run) {
Copy link
Contributor Author

@i386 i386 Apr 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vivek I have skipped serialisation of Item and Run objects in case they are returned by a Cause object. These are evil for performance reasons anyway. I have checked implementations in core and I can't see any that do this but I've added it to be on the safe side (who knows what plugins will do).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a hack but should be fine until we find something else pulling in something else during serialization thats not item or run. We can revisit if its trouble later on.

@i386
Copy link
Contributor Author

i386 commented Apr 23, 2017

@cliffmeyers this is the PR with the hanging tests

Copy link
Collaborator

@vivek vivek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@i386 We could have used causeAction directly instead of wrapping in a backend abstraction, no? I guess there are many actions and we could end up duplicating wrapping them in our backend. Other than that, there are couple of minor comments and looks good.

@Exported(name = CAUSE_OF_BLOCKAGE)
public abstract String getCauseOfBlockage();

@ExportedBean
public static abstract class Cause {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a proper abstraction, perhaps should be pulled out in separate file? Also 'Blue' prefix to be consistent?

public abstract Object getCause();

@Exported(name = "_class")
public abstract String get_Class();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this in abstraction? Stapler does it automatically, or implementations can override that behavior, no?

@@ -25,7 +28,7 @@ public TreePruner accept(Object node, Property prop) {

// for merge properties, the current restrictions on the property names should
// still apply to the child TreePruner
if (prop.merge)
if (prop.merge && child != null)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, please open a PR in stapler with this fix.

@@ -158,6 +160,9 @@ public Object getValue(Property property, Object model, ExportConfig config) thr
printError(model.getClass(), e);
return SKIP;
}
} else if (model instanceof Item || model instanceof Run) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a hack but should be fine until we find something else pulling in something else during serialization thats not item or run. We can revisit if its trouble later on.

@i386
Copy link
Contributor Author

i386 commented Apr 24, 2017

We could have used causeAction directly instead of wrapping in a backend abstraction, no?

@vivek only if you are happy with Cause leaking out into blueocean-rest's public API - which I assume we do not?

@vivek
Copy link
Collaborator

vivek commented Apr 24, 2017

@i386 I meant using action mechanism, causeAction is served via actions element. Well, its now available only via tree query, which we don't have it yet. I guess, we can deal with Cause this way and handle other future actions via action mechanism.

@i386
Copy link
Contributor Author

i386 commented Apr 24, 2017

@vivek we would need to pass the cause through to the client everywhere in the system... (everywhere we use BlueRun) would be easier when we get @kzantow decorated extensions that automatically fetch action's for us.

@vivek
Copy link
Collaborator

vivek commented Apr 24, 2017

@i386 Sounds good 👍

@i386
Copy link
Contributor Author

i386 commented Apr 24, 2017

@vivek fixed the comments about naming here.

@i386
Copy link
Contributor Author

i386 commented Apr 24, 2017

@cliffmeyers @tfennelly in order to merge I need to get this change to jsbuilder merged and a release made tfennelly/jenkins-js-builder#2

Copy link
Collaborator

@vivek vivek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐝

@i386
Copy link
Contributor Author

i386 commented Apr 25, 2017

Requires jsbuilder PR to be merged, released then bumped across all modules.

@i386
Copy link
Contributor Author

i386 commented Apr 27, 2017

@michaelneale
Copy link
Member

🐝 ATH is happy

@i386 i386 merged commit 6d49f4e into master Apr 27, 2017
@i386 i386 deleted the feature/JENKINS-40979 branch April 27, 2017 01:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants