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

Add attachments from the junit-attachments plugin into Jira attachments #144

Merged
merged 13 commits into from
Apr 26, 2024

Conversation

imonteroperez
Copy link

@imonteroperez imonteroperez commented Apr 19, 2024

Highlights

  • Before this PR the attachments added to the Jira tickets are always the stderr, stdout and error stacktrace and details
  • After this PR, if the test result has additional attachments provided by third-party tools (like the junit-attachments publisher) these would be also added to the Jira ticket.

Testing done

  • Tested with Jira and Jenkins locally and working as expected

  • Jenkins attachment

Captura de pantalla de 2024-04-21 21-30-54

  • Jira attachment (contains the one from the junit-attachment in addition to the current ones - stderr, stdout, etc.)

Captura de pantalla de 2024-04-21 21-30-34

Submitter checklist

Preview Give feedback

@imonteroperez imonteroperez force-pushed the additional-attachments branch 3 times, most recently from 28922e1 to 619dea9 Compare April 21, 2024 19:24
@imonteroperez imonteroperez force-pushed the additional-attachments branch from 619dea9 to d06f9e6 Compare April 21, 2024 19:26
@imonteroperez imonteroperez marked this pull request as ready for review April 21, 2024 19:32
Copy link

@cathychan cathychan left a comment

Choose a reason for hiding this comment

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

IMO this should be an opt-in feature. If I have some builds that have massive test attachments, I may not want to include them in the Jira tickets.

@imonteroperez
Copy link
Author

IMO this should be an opt-in feature. If I have some builds that have massive test attachments, I may not want to include them in the Jira tickets.

LGTM, will add a configuration option

@imonteroperez
Copy link
Author

imonteroperez commented Apr 23, 2024

IMO this should be an opt-in feature. If I have some builds that have massive test attachments, I may not want to include them in the Jira tickets.

LGTM, will add a configuration option

Added a configuration option via environment variable on ce6f0c7. I discarded to include an option to the step to keep it simple and keep backward compatibility. Also, the step options are there to specify the behavior (raise, resolve, etc.) but here we want a specific additional operation on raising Jira issues, so that is the reason why I decided to go through an env var.

Also documented in 2353033

@imonteroperez imonteroperez requested a review from cathychan April 23, 2024 07:38
README.md Outdated
Comment on lines 140 to 142
You can use additional environment variables to define additional configuration needs:

* `JIRA_INCLUDE_JUNIT_ATTACHMENTS`: it will include as attachments of a Jira issue additional files from [junit-attachments](https://github.com/jenkinsci/junit-attachments-plugin) plugin. Only on raising new issues.
Copy link
Member

Choose a reason for hiding this comment

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

Why an environment variable and not just a regular boolean data bound setter on the publisher?

Copy link
Author

Choose a reason for hiding this comment

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

At the very beginning considered this #144 (comment) but I'm reconsidering this option and return to the boolean data bound setter on the publisher

Copy link
Member

Choose a reason for hiding this comment

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

All configuration of Pipeline steps, or structs used inside steps (this case), should be via regular data binding. It should be self-documenting as well, using config.jelly. See docs.

Copy link
Author

Choose a reason for hiding this comment

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

Done in a384e3c

@@ -199,6 +225,10 @@ public TestResultAction.Data contributeTestData(Run<?, ?> run, @Nonnull FilePath
}

if(JobConfigMapping.getInstance().getAutoRaiseIssue(project)) {
if (Boolean.getBoolean(System.getenv(JIRA_INCLUDE_JUNIT_ATTACHMENTS))) {
GetTestDataMethodObject methodObject = new GetTestDataMethodObject(run, workspace, launcher, listener, testResult);
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

It retrieves all the attachments per test class and method

@@ -178,7 +204,7 @@ public TestResultAction.Data contributeTestData(Run<?, ?> run, @Nonnull FilePath
throws IOException, InterruptedException {

EnvVars envVars = run.getEnvironment(listener);
Copy link
Member

Choose a reason for hiding this comment

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

This gets the top-level environment for the build. withEnv does not affect it.

Copy link
Author

Choose a reason for hiding this comment

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

You are right, actually, I'm testing this right now and detected this issue. TBH rethinking on to setup a boolean data bound setter better than this.

Copy link
Author

Choose a reason for hiding this comment

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

Addressed in a384e3c

@imonteroperez imonteroperez marked this pull request as draft April 23, 2024 11:15
@imonteroperez imonteroperez requested a review from jglick April 23, 2024 11:42
@imonteroperez imonteroperez marked this pull request as ready for review April 23, 2024 11:43
@@ -130,7 +153,8 @@ private JobConfigMapping.JobConfigEntry getJobConfig() {
*/
@DataBoundConstructor
public JiraTestDataPublisher(List<AbstractFields> configs, String projectKey, String issueType,
boolean autoRaiseIssue, boolean autoResolveIssue, boolean autoUnlinkIssue, boolean overrideResolvedIssues) {
boolean autoRaiseIssue, boolean autoResolveIssue, boolean autoUnlinkIssue, boolean overrideResolvedIssues,
boolean additionalAttachments) {
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

I will do this refactoring outside the scope of this PR. Not sure which parameters can be delegated to a setter given documentation said this is for optional ones.

Copy link
Author

Choose a reason for hiding this comment

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

Created #145 to track this request

Copy link
Member

Choose a reason for hiding this comment

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

Well the new option you just added is clearly optional and so it should be added via a @DataBoundSetter. Refactoring existing options is another matter, but you should never be adding parameters to an existing @DataBoundConstructor.

Copy link
Author

Choose a reason for hiding this comment

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

Addresed for the new optional field in d96ed87

Comment on lines +149 to +150
@DataBoundSetter
public void setAdditionalAttachments(boolean additionalAttachments) {
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be missing the matching getter, which is required. (Do not recall offhand whether that will break the snippet generator, but it is prudent to test that too.)

Copy link
Author

Choose a reason for hiding this comment

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

Addressed on 86b3679

@imonteroperez imonteroperez requested a review from jglick April 25, 2024 14:08
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

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

Looks OK.

@imonteroperez imonteroperez merged commit 13ba2d0 into jenkinsci:master Apr 26, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants