Add copy-to-clipboard button to the build console output

[anhcraft]

• The build's output currently lacks a copy-to-clipboard button. This is a small QoL improvement to quickly copy the console output. The button also supports progressive text output.
• The copy button only supports text via the attribute text. Therefore, this PR also introduces another parameter ref to refer to the target element using the id. Compared to the text approach, it has some advantages: reduces page size, supports formatted logging output and can work across UI components.

Testing done

Manually testing

Before:

After:

Proposed changelog entries

• Add copy-to-clipboard button to the build console output

Submitter checklist

- [ ] The Jira issue, if it exists, is well-described.
- [x] 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](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). 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.
- [x] 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](https://www.jenkins.io/doc/developer/security/csp/)).
- [ ] 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

@jenkinsci/core-pr-reviewers

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](https://github.com/jenkinsci/jenkins/pull/4387)).
- [ ] 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](https://issues.jenkins.io/issues/?filter=12146)).

[welcome[bot]]

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.

[MarkEWaite]

Thanks for the pull request @anhcraft . When you performed the testing, did you confirm that the copied text was inserted into the clipboard? When I've tested these types of pull requests in the past, I needed to use an HTTPS URL to check that the correct text was placed on the clipboard.

[timja]

I needed to use an HTTPS URL to check that the correct text was placed on the clipboard.

It should be a secure context, which is localhost or https url

[anhcraft]

Thanks for the pull request @anhcraft . When you performed the testing, did you confirm that the copied text was inserted into the clipboard? When I've tested these types of pull requests in the past, I needed to use an HTTPS URL to check that the correct text was placed on the clipboard.

It worked for me when running locally. My PR does not change the secure-context check at all. Related PRs: #7665 #8554

[anhcraft]

Confirmed it works for existing copy buttons (script console, agent page )

[lemeurherve]

Would it be possible to put the copy button in the top right corner of the logs like it's done on GitHub amongst others?

Having it alongside titles gives the false impression that's their content which will be copied, it's not obvious at first look these buttons concern the logs block below.

Exemple of a block with a copy button on the top right corner.


Another line.


The end.

[MarkEWaite]

Would it be possible to put the copy button in the top right corner of the logs like it's done on GitHub amongst others?

I think that is a reasonable request for another pull request, since the placement that @anhcraft has selected is consistent with the placement of other copy buttons in Jenkins.

[welcome[bot]]

Congratulations on getting your very first Jenkins core pull request merged 🎉🥳

This is a fantastic achievement, and we're thrilled to have you as part of our community! Thank you for your valuable input, and we look forward to seeing more of your contributions in the future!

We would like to invite you to join the community chats and forums to meet other Jenkins contributors 😊
Don't forget to check out the participation page to learn more about how to contribute to Jenkins.

[reinholdfuereder]

Sorry for commenting on this long ago resolved ticket:

• But where should this "Copy" button be visible?

(Note: I am using Jenkins v2.452.3 and look in classic UI at the "Console Output" view of a recently ran pipeline)

~~Oh! There is a problem with my LDAP configuration -- after Jenkins upgrade from 2.426.3 => 2.452.3 -- I need to look into that problem first...~~

• No, that was just a temporary local LDAP server problem... Jesus!

So actually: when and where should I see this "Copy" button?

[timja]

Its in the top right of the console log:

[reinholdfuereder]

Thanks for your fast response Tim. BUT: I am really sorry, but either I am blind, or I am looking at the completely wrong view?

[timja]

not sure, maybe a plugin is out of date?

[reinholdfuereder]

Well, no, not really: Only Blue Ocean 1.27.14 was just released and I have "just" 1.27.13 installed.

Is the view from my screenshot above the right one? That is, should it be there? (Or am I on the wrong track or view?)

[timja]

Should be, I'm not sure why its not there for you

[reinholdfuereder]

Oh, maybe this comment explains it: https://github.com/jenkinsci/jenkins/pull/9169#issuecomment-2060538377

Because I was "only" looking at the "Console output" of a scripted pipeline job so far... (We do not have any freestyle jobs at all)

[timja]

Which was ported to pipeline in https://github.com/jenkinsci/workflow-job-plugin/pull/439

I tested with a pipeline

[reinholdfuereder]

Well, no, not really: Only Blue Ocean 1.27.14 was just released and I have "just" 1.27.13 installed. And besides that now "Configuration as Code" (1810 => 1836) and GitHub Branch Source (1789 => 1790) and Pipeline API (1316 => 1322).

Oh, the version of aforementioned "workflow-job" plugin installed is only 1400.v7fd111b_ec82f (released already ~6 months ago) -- and for my version of Jenkins core (2.425.3) there is (according to the Jenkins plugin manager Web UI) no update available of this plugin. Although there are/were newer releases of this plugin, like e.g. 1436.vfa_244484591f (2 weeks ago) with the aforementioned fix for pipeline (https://github.com/jenkinsci/workflow-job-plugin/issues/439).

That explains the missing feature. Thanks!

However, I am wondering why I don't get this update. When I specify this latest version of the plugin in the corresponding Job DSL tests I actually get this (matching) error message:

0.864 [id=65]	SEVERE	jenkins.InitReactorRunner$1#onTaskFailed: Failed Loading plugin Pipeline: Job v1436.vfa_244484591f (workflow-job)
java.io.IOException: Failed to load: Pipeline: Job (workflow-job 1436.vfa_244484591f)
 - Jenkins (2.454) or higher required
	at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:992)
	at hudson.PluginManager$2$1$1.run(PluginManager.java:552)
	at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:177)
	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:305)
	at jenkins.model.Jenkins$5.runTask(Jenkins.java:1175)
	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:221)
	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:120)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

And in https://github.com/jenkinsci/workflow-job-plugin/blob/master/pom.xml I see something that may be related?

<jenkins.version>2.454</jenkins.version>

So that explains everything?

[timja]

Yup exactly so it'll be available in the next LTS version which will be released on 7th August