custom detailsURL for recordIssues and recordCoverage

[esatterwhite]

What feature do you want to see added?

The warnings plugin publishes the results to GitHub checks, when possible. The used publishChecks function allows you to specify a custom URL that is used as the link at the bottom of the checks. The Jenkins warnings plugin sets this value to the URL of the Jenkins build job, which isn't always accurate, or in out case publicly accessible. Rather than spin up a second instance of Jenkins, or try to make certain jobs public, we rather just change the URL that link points to.

We can do this with publish checks manually, but then we lose all of the nice reporting generated by recordIssues, and recordCoverage to both jenkins and github. Which is less than ideal.

recordIssues(
  ...
, checksDetailsUrl: 'http://my.public.help.com'
)

Upstream changes

I think this logic found here is where this is actually happening.

There needs to be away to provide a custom url. it is currently always forcing a url to the job on the jenkins UI.

Are you interested in contributing this feature?

yes. Some direction on what needs to change would be helpfule

[uhafner]

Wouldn't it already help to simply change the Jenkins URL in the Jenkins system configuration?

If not, the new property can be simply added. You already mentioned the correct class that is responsible to publish the checks. Is the URL absolute or should there be some expansions computed (e.g. the name of the job?)?

We need

• A new property with getter, setter, UI configuration, and help in RecordIssuesStep, PublishIssuesStep, and IssuesRecorder: the new property could be implemented in a similar way to checksAnnotationScope and should be named checksDetailsUrl. If not set it should default to the existing value.
• A new parameter in WarningChecksPublisher for the new URL.
• A test case that shows that the new URL is correctly used.

[esatterwhite]

We run multiple github organizations, some are internal facing only, and some are public. The common case the default jira URL is fine and is desired. Changing the url would change it to something for every repo, or all repos in the org.

in the case of our public facing this, each wants to have that url be something that points to a local doc, or wiki page, which will all be different, and may even change per check.

[esatterwhite]

You already mentioned the correct class that is responsible to publish the checks. Is the URL absolute or should there be some expansions computed (e.g. the name of the job?)?

to me its absolute - http://github.com/owner/repo/some-doc-i-made-up.md

If its possible to provide templates for the csm repo + owner / org. That'd be cool. Not sure what I would need to do that for that. some guidance would be appreciated.

[esatterwhite]

• A new property with getter, setter, UI configuration, and help in RecordIssuesStep, PublishIssuesStep, and IssuesRecorder: the new property could be implemented in a similar way to checksAnnotationScope and should be named checksDetailsUrl. If not set it should default to the existing value.

Where would these go. links to files + lines would be helpful. I'm not sure what exactly need to happen there, or what you want me to do

[esatterwhite]

• and should be named checksDetailsUrl

@uhafner the property in general should be named checksDetailsUrl ? why not detailsURL? that is the property that the checks API uses. feels a bit more consistent / simple instead of introducing another property that means / does the same thing but is named something slightly differently

[KalleOlaviNiemitalo]

I expected this would go in WithChecksStep and ChecksInfo, which already have a way to override the name.

[esatterwhite]

I expected this would go in WithChecksStep and ChecksInfo, which already have a way to override the name.

@KalleOlaviNiemitalo
Wouldn't both things need to happen?

As I understand it the checks API doesn't merge checks configurations. so if I set a detailsURL via withChecks and call recordIssues with out it, would it not just set it back to the default?

[esatterwhite]

I can move this to the checks-api plugin. If it is just a matter of updating withChecks. that seems simple to do

[esatterwhite]

see jenkinsci/checks-api-plugin#328

[KalleOlaviNiemitalo]

warnings-ng-plugin/plugin/src/main/java/io/jenkins/plugins/analysis/core/steps/WarningChecksPublisher.java

Lines 109 to 111 in 277a958

	var checksName = Optional.ofNullable(checksInfo).map(ChecksInfo::getName)
	.filter(StringUtils::isNotEmpty)
	.orElse(labelProvider.getName());

This takes the name from ChecksInfo if available, otherwise from the analysis tool.

warnings-ng-plugin/plugin/src/main/java/io/jenkins/plugins/analysis/core/steps/WarningChecksPublisher.java

Line 124 in 277a958

.withDetailsURL(action.getAbsoluteUrl())

That then takes the URL of the warnings result and passes it to Checks API. Could be changed to read the URL from ChecksInfo if available.

I suppose I had the false idea that either Checks API itself or plugins like GitHub Checks would find ChecksInfo from the context of the current pipeline step and override the properties of ChecksDetails accordingly. If support for overriding the URL via ChecksInfo must instead be implemented separately in each plugin that publishes ChecksDetails to Checks API, then that reduces the value of such an approach and can disappoint users if they try to use this feature and find that it isn't supported by all such plugins (e.g. xunit) yet.

[esatterwhite]

@KalleOlaviNiemitalo sorry, I'm not sure what the desired path is here.
update checksinfo in the checks-api-plugin or do it here? or do both and update all the plugins?