Motivation

Jenkins core and various plugins link directly to the /console page for builds in a number of situations, for example not only the direct link to the console in the sidebar of runs, but also the status icon in the build history widget in Jenkins core and the "proceed"/"abort" button for input steps in pipeline-input-step.

A few different plugins have or are working on alternate console views, primarily for Pipelines. Blue Ocean has one, although it is not really a direct replacement for the normal console. Pipeline Graph View plugin is working on a new console view for Pipelines as well. CloudBees is also working on a proprietary log viewer plugin for Pipelines.

We would like for there to be an API that plugins which provide alternate log visualizations can use to handle links to the console from other plugins. Display URL API plugin offers a mechanism to create "display URLs" for things like external notifications (and for users to choose their personal preferred URL provider), which is useful, but we would like to be able to alter the behavior of existing links in Jenkins, which would require changes to Jenkins core.

Prototype Implementations

We have prototyped two main approaches for making this possible. In both approaches we define two new APIs:

1. In Jenkins core, we add an ExtensionPoint named ConsoleURLProvider (name not final), with a single extensible method with a signature like String ConsoleURLProvider.getUrl(Run).
2. In display-url-api, we add a new DisplayURLProvider.getConsoleUrl(Run) method, and we implement ConsoleURLProvider with a new @Extension that delegates to the new method.

Plugins which want to provide an alternate console view would implement DisplayURLProvider and override getConsoleUrl as needed.

For code in Jenkins core or plugins that wants to link to the console for a build, we have prototyped two possible approaches:

Approach 1: Modify hard-coded console links in core and plugins to use a new redirect URL

We would create a new Run.getConsoleDisplayRedirect method (name not final), which uses the ConsoleURLProvider with the highest registered ordinal value to get the console URL, but falls back to /console in case there is no such extension. All existing code that links to the console in Jenkins core and in all plugins would need to change hard-coded references to /console to /consoleDisplayRedirect. Here is an incomplete search of references that might need to be changed.

This approach seems straightforward and relatively safe in terms of compatibility, but it is not ideal to have to adapt all downstream plugins to use the new URL. If we went down this approach we would look through all plugins in the Jenkins BOM and file PRs to adapt them as part of this change, but we would probably not do so for all plugins, at least not to start with.

Approach 2: Turn <run>/console itself into a redirect

We would define a new Run.doConsole method that uses Stapler APIs to redirect the page to ConsoleURLProvider.getUrl for the extension with the highest ordinal value, falling back to serving console.jelly if there is no such extension.

The benefit of this approach is we don't need to change any existing code in core and plugins that links to <run>/console.

On the other hand, this approach seems to be potentially a little more dangerous (bugs leading to infinite redirects), a bit slower (because of the redirect), and perhaps logically wrong in some cases where an existing /console link really should go to the classic console view.

Compatibility and related concerns

• With either approach, the behavior of the /consoleText and /consoleFull views would be unchanged. The former is accessible via a sidebar link on builds, but the latter is normally only accessed from the UI on the /console view.
  • We think that any programmatic access to the console is most likely to go through /consoleText and so be unaffected by these changes.
• With the automatic redirect approach, we might need to add a new way to link to the classic console that would bypass the redirect handling (e.g. /consoleFull).
• TBD, I am sure we are missing some other nuances here