[JENKINS-71715] Allow plugins with alternate build log visualizations to handle console links from core and other plugins #8321

jgreffe · 2023-08-01T10:45:29Z

This PR introduces a new extension point ConsoleUrlProvider, which is intended to be used by Jelly files that link to the build console and plugins that redirect to the build console, in order for plugins which provide special build console visualizations (such as Pipeline: Graph View and Blue Ocean) to be able to serve their own visualizations in those contexts.

See downstream PRs here:

An example of implementing ConsoleUrlProvider: [JENKINS-71715] Update minimum supported Jenkins version to 2.440 to be able to implement new ConsoleUrlProvider API from Jenkins core pipeline-graph-view-plugin#289
An example of using Functions.getConsoleUrl from a plugin: [JENKINS-71715] Update minimum supported Jenkins version to 2.440 to be able to use new ConsoleUrlProvider API to link to Pipeline build console page workflow-job-plugin#373
An example of using ConsoleUrlProvder.getRedirectUrl: [JENKINS-71715] Update minimum supported Jenkins version to 2.440 to be able to use new ConsoleUrlProvider extension point to redirect to the console pipeline-input-step-plugin#145

I reviewed plugins in https://github.com/jenkinsci/bom for console links to see how they are affected by these changes, see #8321 (comment).

Testing done

New automated test added.

You can manually test the PR by running jenkinsci/pipeline-graph-view-plugin#289 by itself. Note that you will have to configure "Console URL Provider" in either the global configuration or your user configuration for anything to happen.

Here is a video of me testing the downstream changes with a Pipeline build:

Screen.Recording.2023-08-09.at.1.15.52.PM.mov

Proposed changelog entries

Introduce an API for build visualization plugins to serve alternative build console views and an API for plugins to produce links to the build console.

Proposed upgrade guidelines

N/A

Submitter checklist

The Jira issue, if it exists, is well-described.
The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
There is automated testing or an explanation as to why this change has no tests.
New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
For dependency updates, there are links to external changelogs and, if possible, full differentials.
For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@dwnusbaum

Before the changes are marked as ready-for-merge:

Maintainer checklist

There are at least two (2) approvals for the pull request and no outstanding requests for change.
Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
Proper changelog labels are set so that the changelog can be generated automatically.
If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

… to handle console links from core and other plugins

welcome · 2023-08-01T10:45:43Z

Yay, your first pull request towards Jenkins core was created successfully! Thank you so much!

A contributor will provide feedback soon. Meanwhile, you can join the chats and community forums to connect with other Jenkins users, developers, and maintainers.

core/src/main/java/hudson/link/ConsoleURLProvider.java

daniel-beck · 2023-08-02T11:35:24Z

core/src/main/java/hudson/link/ConsoleURLProvider.java

+        public String getRoot() {
+            String root = Jenkins.get().getRootUrl();
+            if (root == null) {
+                root = "http://unconfigured-jenkins-location/";


Is there a legitimate use case for when this code would be reached?

Display URL API has this because the URLs are used outside Jenkins and computed in a non-request context. It seems these URLs are always used in a request context, as they're used to render parts of the UI?

Good point, it would probably be better to design the new API to work with URLs relative to the context root, and then use something like '/' + Stapler.getCurrentRequest().getContextPath() + getConsoleURL(run) to build the console URLs.

The implementation of the extension that should go into jenkinsci/display-url-api-plugin#194 would need to convert the absolute URLs into context path-relative URLs though, and I guess what I was thinking here would no longer apply, since we would want to use ConsoleURLProvider for all links in the Jenkins UI and DisplayUrlProvider.getConsoleUrl only when producing external links.

EDIT: Although now I wonder if there is a use case where people want to redirect to a completely separate external logging system, e.g. maybe you use opentelemetry as described here and want to direct users to some Elasticsearch frontend instead.

EDIT: Although now I wonder if there is a use case where people want to redirect to a completely separate external logging system

That seems like something that could be interesting. Summoning @cyrille-leclerc WDYT?

Thinking about it some more -- just after the ping comment, sorry Cyrille -- this could also easily be implemented by having a Jenkins-internal URL that redirects to the outside system, instead of linking there directly.

Thanks @daniel-beck. Regarding the OpenTelemetry integrations where Jenkins pipeline logs are persisted in an external logs management system rather than in the Jenkins home, all integrations I am aware of want to

Use Jenkins's built-in pipeline logs visualization UX to render the logs stored externally

Offer a visualization in their own logs management GUI, often workflows combining metrics, traces, and logs of the pipeline executions.

I don't see any OTel integration scenario wanting to create an alternative pipeline logs visualization GUI in Jenkins.

Does it make sense?

core/src/main/java/hudson/link/ConsoleURLProvider.java

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

daniel-beck · 2023-08-02T11:38:27Z

core/src/main/java/hudson/link/ConsoleURLProvider.java

@@ -0,0 +1,59 @@
+package hudson.link;


Please use jenkins.… packages for new types.

Is it better to create a jenkins.console package and put it there or put it in the already-existing hudson.console package?

core/src/main/java/hudson/link/ConsoleURLProvider.java

we usually don't put versions but put todo instead and these versions get resolved _after_ merges. Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>

jglick · 2023-08-04T15:37:03Z

Note to self that if merged, #7633 could take advantage of this API. Currently it just redirects to the index page of the new build, but it would be better to go straight to the log.

core/src/main/java/jenkins/link/ConsoleURLProvider.java

…ons.getContextRelativeUrl

daniel-beck

How would this be used by an implementation? Given this looks at the highest priority implementation in the static extension list, do admins need https://plugins.jenkins.io/extension-filter/ to configure that? Or is the expectation really that nothing but display-url-api implements this? The answer should be documented in Javadoc.

core/src/main/java/hudson/Functions.java

core/src/main/java/jenkins/link/ConsoleURLProvider.java

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

dwnusbaum · 2023-08-04T17:27:46Z

How would this be used by an implementation? Given this looks at the highest priority implementation in the static extension list, do admins need https://plugins.jenkins.io/extension-filter/ to configure that? Or is the expectation really that nothing but display-url-api implements this?

I am going to change things. I think I'll swap to looping over all extensions, and then allowing implementations to return null if they don't want to do anything for a particular run. Thinking about it some more, it might be better to only have actual visualization plugins implement the extension point if desired and leave display-url-api for external URLs only.

…ConsoleUrl method for use in Jelly files

dwnusbaum · 2023-08-04T21:45:06Z

core/src/main/java/jenkins/console/ConsoleURLProvider.java

+     * @param run the build
+     * @return the URL for the console for the specified build, relative to the web server root
+     */
+    static @NonNull String getRedirectUrl(Run<?, ?> run) {


This method is intended to be used directly in cases where Java code wants to redirect a request to the console as in jenkinsci/pipeline-input-step-plugin#145.

core/src/main/resources/hudson/model/AbstractBuild/changes.jelly

core/src/main/resources/lib/hudson/buildProgressBar.jelly

dwnusbaum · 2023-08-04T21:47:57Z

core/src/main/resources/lib/hudson/project/console-link.jelly

+            <l:task href="${h.getConsoleUrl(it)}" icon="icon-terminal icon-md" title="${%Console Output}"/>
            <l:task href="${buildUrl.baseUrl}/consoleText" icon="icon-document icon-md" title="${%View as plain text}"/>


I am not entirely sure what we want to do about this case. I think it makes sense to redirect the main "console output" link, but IDK if we should force-show the "View as plain text" link when the console URL is non-default or something like that.

dwnusbaum · 2023-08-04T21:50:07Z

core/src/main/java/hudson/Functions.java

+     * @return the absolute URL for accessing the specified build's console
+     * @since TODO
+     */
+    public static @CheckForNull String getConsoleUrl(Run<?, ?> run) {


This method is intended for use in Jelly files (both in core and in plugins). I think it is a little cleaner to put it here rather than directly on Run, but that is just my opinion.

core/src/main/java/jenkins/console/ConsoleURLProvider.java

dwnusbaum · 2023-08-04T22:04:38Z

core/src/main/java/jenkins/console/ConsoleURLProvider.java

+     */
+    static @NonNull String getRedirectUrl(Run<?, ?> run) {
+        String url = null;
+        for (ConsoleUrlProvider provider : ExtensionList.lookup(ConsoleUrlProvider.class)) {


@daniel-beck raised a few important points in #8321 (review) and I am not entirely sure how we should address them.

With my latest changes to the API, we can create implementations that only care about Pipelines, or builds with odd numbers, etc. However, if (for example) both Blue Ocean and Pipeline Graph View wanted to implement ConsoleUrlProvider for all Pipeline builds, and you have both plugins installed on a single controller, they would compete for precedence based on ordinal. How do we want to address this? I can see a few approaches:

Do nothing, let admins use https://plugins.jenkins.io/extension-filter/ as needed. Maybe this is good enough if we only expect a few overlapping implementations of this extension point, especially if we think the implementations are likely to come from competing plugins where admins are going to choose one instead of installing them all at the same time.

Provide a GlobalConfiguration UI in core to allow admins to select which ConsoleUrlProvider extensions should be enabled on a given controller, or allow them to be sorted based on the admin's preference. Same end result as above, though arguably more user-friendly, but it adds additional implementation complexity.

Provide a user-based configuration in core to let users select which ConsoleUrlProvider extensions they want to allow, or allow them to be sorted based on the user's preference. Adds even more implementation complexity than the above options, but now if there are two plugins installed with competing ConsoleUrlProvider implementations, individual users get to pick which one they want to use. (I think all of the links in question are generated dynamically during page rendering/request handling and so would be able to use the current user's preferences without significant technical issues, but perhaps it would be more complex than that.)

For now at least I need to update jenkinsci/pipeline-graph-view-plugin#288 and jenkinsci/pipeline-input-step-plugin#145 based on the latest changes.

I suspect you will want 2 and 3, admins to set a default and allow users to override it

Missed this thread and posted #8321 (comment). For now IMO option 2 should be enough (option 3 only if sufficient user demand exists).

I feel you'll get users that are used to it but some users who would want the other implementation, also with the display url only having a per user setting it seems weird for this one not to?

with the display url only having a per user setting

For what it's worth, related to this work we will add a global configuration to display-url-api to allow admins to pick the default setting for users who have not yet configured their own preference. (Right now I think the default behavior is effectively random if you have more than one DisplayUrlProvider extension on a controller.)

As far as whether we want to allow per-user settings here, my main hesitation is just that it adds complexity to core and I am not sure how useful it will be in practice. For the record, I don't know if it makes sense to actually implement the new API in Blue Ocean because I don't think that it is a sufficient replacement for the main console view in general.
That leaves pipeline-graph-view as the only OSS visualization plugin that I was planning on filing a PR against for now (let me know if I am missing something obvious). Beyond that, CloudBees has a proprietary visualization plugin that we would like to have implement the new API for most Pipelines. All that to say, I am not sure how often conflicts would occur in practice, at least for now.

If you see this API as one intended for admins to control the UX of their instance and guide users to a preferred console visualization, then having a global configuration alone seems fine. If you think it is just a matter of personal preference then a per-user configuration makes sense.

For a cloudbees plugin it may make more sense as a control of the whole instance.

In the case of pipeline graph view plugin someone may want to fallback to the default console view if it doesn't handle something for them or they have used it for 10+ years and do not want to change.

also PGV doesn't support freestyle builds at all and I haven't seen any handling for that in the downstream PR.

also PGV doesn't support freestyle builds at all and I haven't seen any handling for that in the downstream PR.

Yes sorry, all of the downstream PRs need to be updated. I will get to that later today.

See 018789a and let me know what you think. We can dial it back as desired.

this looks good to me

daniel-beck · 2023-08-05T10:25:00Z

I think I'll swap to looping over all extensions, and then allowing implementations to return null if they don't want to do anything for a particular run

I'm wondering what the configuration would look like then if you end up with two implementations. Find out whichever is the higher precedence (how?) and disable that in a plugin-defined manner, so it falls through to the other, seems like an awkward admin experience.

A global configuration that only shows up when you have a non-default implementation (similar to Artifact Management for Builds) might be a reasonable UI for this: Admins add/remove/sort descriptors of what's not the default. Could even gracefully reduce to an enable/disable checkbox if there's just one implementation.

To clarify, the above suggestion is not a requirement, but I think it's important for this PR to provide an answer to how two implementations interact / how to configure them. I don't think you want to go the way of localization-support which implements such a narrow extension point it can reasonably require Highlander status.

…soleUrlProvider

core/src/main/java/jenkins/console/ConsoleUrlProvider.java

daniel-beck · 2023-09-27T12:01:16Z

Noting #8403 which is probably relevant for this PR.

core/src/main/java/jenkins/console/ConsoleUrlProvider.java

core/src/main/java/jenkins/console/ConsoleUrlProviderGlobalConfiguration.java

…ser providers fail to provide a valid URL

dwnusbaum · 2023-09-27T19:01:56Z

Noting #8403 which is probably relevant for this PR.

Ok, should I go ahead and move the new global configuration from this PR into that category? I think it is conceptually very similar to display-url-api, which was mentioned in that PR:

Could possibly move the Display notification URL provider to appearance too? (the thing that selects Classic, Blue Ocean or Pipeline Graph View)

timja · 2023-09-27T21:12:38Z

Yes please

…ranceCategory

daniel-beck · 2023-09-28T07:24:24Z

It's not that easy though, otherwise we get

Since both category and this extension point are a core feature, this PR could add special behavior for this case in

jenkins/core/src/main/java/jenkins/appearance/AppearanceGlobalConfiguration.java

Lines 56 to 57 in 9dabd87

    
           if (Functions.getSortedDescriptorsForGlobalConfigByDescriptor(FILTER).isEmpty()) { 
        
               return null;

…derGlobalConfiguration is disabled and would be the only option on the page

jeromepochat · 2023-10-19T09:01:10Z

I just noticed that "Appearance" page is still reachable through direct URL http://.../manage/appearance/ in case of single ConsoleUrlProvider available. Could the link be enabled or disabled similarly to action button (depending on number of available providers)?

dwnusbaum · 2023-10-19T13:56:02Z

Could the link be enabled or disabled similarly to action button (depending on number of available providers)?

I'm not 100% sure, but I don't think there is a simple way to do it. That behavior should be the same though with or without this PR: if you install the latest Jenkins weekly, do not install any plugins, and go to manage/appearance/, you will see a mostly blank page.

jeromepochat · 2023-10-19T16:09:20Z

I'm not 100% sure, but I don't think there is a simple way to do it. That behavior should be the same though with or without this PR: if you install the latest Jenkins weekly, do not install any plugins, and go to manage/appearance/, you will see a mostly blank page.

👍

I wrongly thought the "Appearance" page was introduced by this PR.

Then everything looks good to me.

fcojfernandez

Nice feature

fcojfernandez · 2023-10-25T15:21:40Z

core/src/main/resources/jenkins/console/ConsoleUrlProviderUserProperty/config.jelly

+<j:jelly xmlns:j="jelly:core" xmlns:f="/lib/form">
+    <j:if test="${descriptor.enabled}">
+        <f:invisibleEntry>
+          <!-- Dummy field to always have an entry in form submissions so users can delete all providers. -->


how I hate that ...

Do not do it this way. Rather start doConfigSubmit or whatever by nulling out the field before binding properties.

IIRC, both were needed, otherwise configure didn't even get called. I will check again though, perhaps this can be deleted.

Ah yeah I think this behavior was specific to user properties actually. I'll still check it again though.

Probably what you ran into is that form binding only provides a JSON element for a list if it has at least one entry. So for a top-level (reconfigurable) object, if you just use the default bindJSON, after deleting all elements of a list and saving, no change is applied to that property. The workaround is to simply null out any list-valued fields before calling bindJSON.

For ConsoleUrlProviderGlobalConfiguration, yes, that was a problem and that is how I fixed it.

ConsoleUrlProviderUserProperty is different though. User.doConfigSubmit is unusual and has complex logic regarding creating new properties vs reconfiguring existing ones. IIRC, in the problematic case, since ConsoleUrlProviderUserProperty only has a single List field, this condition is (EDIT) false because the property itself is not present in the submitted JSON at all, and so the logic there chooses to reuse the existing property if one exists.

Whether that logic was intentional was not clear to me. Perhaps these lines should be moved inside of this block, so that any properties not present in the submission are deleted, but I have no idea if anything relies on the current behavior (perhaps this case is intended to preserve user properties that do not offer any GUI configuration?) and it was not something I wanted to look into here.

perhaps this case is intended to preserve user properties that do not offer any GUI configuration?

Perhaps. (Or those whose GUI configuration is on a separate page.)

jenkins/core/src/main/java/hudson/model/User.java

Line 881 in c9947a3

if (o != null) {

is true because the property itself is not present in the submitted JSON at all

false you mean? Smells like a bug in the form submission JSON generator; it should at least create {} maybe with _class.

Yes sorry I meant false.

daniel-beck

Works fine in testing with the downstream PRs. Code and tests look reasonable as well.

Some (optional) thoughts:

It'd be useful to have developer guidelines for implementations. For example, implementing plugins no longer need a separate link to their own console (as the current PR of pipeline-graph-view still does), but OTOH would be good for them to a link to the legacy build log in their custom UI.
The current wording focuses on the URLs/links because that's what it does from a technical POV. From a user POV, it seems to me it's more about the chosen build log visualization. Perhaps someone more in the PM/PO/UX space can provide feedback on the name of this?

core/src/main/resources/jenkins/console/ConsoleUrlProviderUserProperty/config.properties

core/src/main/resources/jenkins/console/ConsoleUrlProviderGlobalConfiguration/config.properties

core/src/main/resources/jenkins/console/ConsoleUrlProviderGlobalConfiguration/config.jelly

dwnusbaum · 2023-10-30T18:18:46Z

The current wording focuses on the URLs/links because that's what it does from a technical POV. From a user POV, it seems to me it's more about the chosen build log visualization

Sure, we could change "Console URL Provider" to "Console Visualization Provider" at least in the user-facing text, and also the class names if desired.

dwnusbaum · 2023-10-30T19:01:31Z

I will also add a note for implementors to the ConsoleUrlProvider Javadoc regarding some of the points you mentioned.

implementing plugins no longer need a separate link to their own console

I don't think this is so clear-cut. The console visualization plugins cannot trivially tell whether the current user has their visualization selected to know if the link is redundant (they could consult ConsoleUrlProvider.getRedirectUrl but it would be somewhat awkward), and even if a user prefers one visualization, they may still want to be able to easily access other visualizations. It seems simplest to me to just leave the redundant links in place in the sidepanel of the build for now.

…, and filter out default provider in global config Co-authored-by: Daniel Beck <daniel-beck@users.noreply.github.com>

core/src/main/java/jenkins/console/ConsoleUrlProviderGlobalConfiguration.java

MarkEWaite · 2023-11-08T15:20:31Z

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

dwnusbaum · 2023-11-10T14:03:58Z

The current wording focuses on the URLs/links because that's what it does from a technical POV. From a user POV, it seems to me it's more about the chosen build log visualization

Sure, we could change "Console URL Provider" to "Console Visualization Provider" at least in the user-facing text, and also the class names if desired.

@daniel-beck do you think I should make this change, or do you have any other suggestions?

daniel-beck · 2023-11-10T14:49:48Z

do you think I should make this change, or do you have any other suggestions?

Depends on whether you think this is easy followup, I guess (assuming you agree it would be a worthwhile change)? As I wrote, it's optional.

dwnusbaum · 2023-11-10T14:52:15Z

Yes it is easy to change later (assuming we do not care about the class names). If you think "Console visualization provider" is better than "Console URL provider" though then I figure we might as well go ahead and change the text on the configuration pages here.

core/src/main/java/jenkins/console/ConsoleUrlProviderGlobalConfiguration.java

[JENKINS-71715] Allow plugins with alternate build log visualizations…

4862fa0

… to handle console links from core and other plugins

jgreffe added 2 commits August 1, 2023 13:05

Merge branch 'master' into JENKINS-71715_first-approach

ecc7e50

Merge branch 'master' into JENKINS-71715_first-approach

d1f3aa2

dwnusbaum reviewed Aug 1, 2023

View reviewed changes

core/src/main/java/hudson/link/ConsoleURLProvider.java Outdated Show resolved Hide resolved

core/src/main/java/hudson/link/ConsoleURLProvider.java Outdated Show resolved Hide resolved

jgreffe added 2 commits August 1, 2023 20:28

[JENKINS-71715] Apply suggestions with ordinal extension and @SInCE TODO

4316970

[JENKINS-71715] Public @extension

519adfd

daniel-beck reviewed Aug 2, 2023

View reviewed changes

batmat and others added 2 commits August 4, 2023 17:02

Add or fix @SInCE todo

618f538

we usually don't put versions but put todo instead and these versions get resolved _after_ merges. Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>

[JENKINS-71715] Apply suggestions from reviews

f8fa8fe

jgreffe requested review from dwnusbaum and daniel-beck August 4, 2023 15:13

dwnusbaum reviewed Aug 4, 2023

View reviewed changes

core/src/main/java/jenkins/link/ConsoleURLProvider.java Outdated Show resolved Hide resolved

core/src/main/java/jenkins/link/ConsoleURLProvider.java Outdated Show resolved Hide resolved

[JENKINS-71715] Switch ConsoleURLProvider to interface and add Functi…

a976eb6

…ons.getContextRelativeUrl

daniel-beck reviewed Aug 4, 2023

View reviewed changes

core/src/main/java/hudson/Functions.java Show resolved Hide resolved

core/src/main/java/jenkins/link/ConsoleURLProvider.java Outdated Show resolved Hide resolved

core/src/main/java/hudson/model/Run.java Outdated Show resolved Hide resolved

dwnusbaum marked this pull request as draft August 4, 2023 19:39

[JENKINS-71715] Refactor ConsoleUrlProvider API and add Functions.get…

d853004

…ConsoleUrl method for use in Jelly files

dwnusbaum reviewed Aug 4, 2023

View reviewed changes

dwnusbaum changed the title ~~[JENKINS-71715] Allow plugins with alternate build log visualizations…~~ [JENKINS-71715] Allow plugins with alternate build log visualizations to handle console links from core and other plugins Aug 4, 2023

dwnusbaum added 5 commits August 7, 2023 10:23

[JENKINS-71715] Fix casing of ConsoleURLProvider.java

2dd4e97

[JENKINS-71715] Add global and per-user configuration options for Con…

018789a

…soleUrlProvider

[JENKINS-71715] Fix Javadoc reference

3d9b41c

[JENKINS-71715] Remove outdated TODO comment

7305016

Merge branch 'master' into JENKINS-71715_first-approach

6491cbb

dwnusbaum reviewed Aug 7, 2023

View reviewed changes

core/src/main/java/jenkins/console/ConsoleUrlProvider.java Outdated Show resolved Hide resolved

daniel-beck added the web-ui The PR includes WebUI changes which may need special expertise label Sep 27, 2023

daniel-beck reviewed Sep 27, 2023

View reviewed changes

[JENKINS-71715] Ignore invalid URLs and consult global providers if u…

b5420ad

…ser providers fail to provide a valid URL

[JENKINS-71715] Move ConsoleUrlProviderGlobalConfiguration into Appea…

bcf46b6

…ranceCategory

[JENKINS-71715] Hide AppearanceGlobalConfiguration if ConsoleUrlProvi…

a4d5a21

…derGlobalConfiguration is disabled and would be the only option on the page

daniel-beck self-requested a review October 4, 2023 08:43

jeromepochat approved these changes Oct 19, 2023

View reviewed changes

fcojfernandez approved these changes Oct 25, 2023

View reviewed changes

daniel-beck approved these changes Oct 30, 2023

View reviewed changes

dwnusbaum and others added 2 commits October 30, 2023 16:36

[JENKINS-71715] Update help text and Javadoc based on review feedback…

64c3faa

…, and filter out default provider in global config Co-authored-by: Daniel Beck <daniel-beck@users.noreply.github.com>

Merge branch 'master' into JENKINS-71715_first-approach

7e51da5

dwnusbaum reviewed Oct 30, 2023

View reviewed changes

core/src/main/java/jenkins/console/ConsoleUrlProviderGlobalConfiguration.java Outdated Show resolved Hide resolved

[JENKINS-71715] getProvidersDescriptors can be an instance method

88ea796

comment-ops-bot bot added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Nov 8, 2023

MarkEWaite merged commit b9b3e6b into jenkinsci:master Nov 18, 2023
16 checks passed

MarkEWaite self-assigned this Nov 18, 2023

timja reviewed Jan 20, 2024

View reviewed changes

core/src/main/java/jenkins/console/ConsoleUrlProviderGlobalConfiguration.java Show resolved Hide resolved

		<l:task href="${h.getConsoleUrl(it)}" icon="icon-terminal icon-md" title="${%Console Output}"/>
		<l:task href="${buildUrl.baseUrl}/consoleText" icon="icon-document icon-md" title="${%View as plain text}"/>

[JENKINS-71715] Allow plugins with alternate build log visualizations to handle console links from core and other plugins #8321

[JENKINS-71715] Allow plugins with alternate build log visualizations to handle console links from core and other plugins #8321

Conversation

jgreffe commented Aug 1, 2023 • edited by MarkEWaite Loading

Testing done

Proposed changelog entries

Proposed upgrade guidelines

Submitter checklist

Desired reviewers

Maintainer checklist

welcome bot commented Aug 1, 2023

Choose a reason for hiding this comment

dwnusbaum Aug 3, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cyrille-leclerc Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jglick commented Aug 4, 2023

daniel-beck left a comment

Choose a reason for hiding this comment

dwnusbaum commented Aug 4, 2023 • edited Loading

Choose a reason for hiding this comment

dwnusbaum Aug 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dwnusbaum Aug 4, 2023 • edited Loading

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

daniel-beck commented Aug 5, 2023 • edited Loading

daniel-beck commented Sep 27, 2023

dwnusbaum commented Sep 27, 2023

timja commented Sep 27, 2023

daniel-beck commented Sep 28, 2023

jeromepochat commented Oct 19, 2023

dwnusbaum commented Oct 19, 2023 • edited Loading

jeromepochat commented Oct 19, 2023

fcojfernandez 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

dwnusbaum Oct 25, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniel-beck left a comment

Choose a reason for hiding this comment

dwnusbaum commented Oct 30, 2023

dwnusbaum commented Oct 30, 2023 • edited Loading

MarkEWaite commented Nov 8, 2023

dwnusbaum commented Nov 10, 2023

daniel-beck commented Nov 10, 2023

dwnusbaum commented Nov 10, 2023

jgreffe commented Aug 1, 2023 •

edited by MarkEWaite

Loading

dwnusbaum Aug 3, 2023 •

edited

Loading

cyrille-leclerc Aug 7, 2023 •

edited

Loading

dwnusbaum commented Aug 4, 2023 •

edited

Loading

dwnusbaum Aug 4, 2023 •

edited

Loading

dwnusbaum Aug 4, 2023 •

edited

Loading

daniel-beck commented Aug 5, 2023 •

edited

Loading

dwnusbaum commented Oct 19, 2023 •

edited

Loading

dwnusbaum Oct 25, 2023 •

edited

Loading

dwnusbaum commented Oct 30, 2023 •

edited

Loading