Jenkins 2.582 - Update Center Root and Console Log Tail

Jenkins weekly jenkins-2.582 was published on 20 September 2026. The change operators will care about first is a new update center root certificate covering 2026 through 2036, shipped while the current root is still valid through 2028. The same weekly also repairs plain text console tails that skipped a trailing partial line, and it fixes the OpenSearch descriptor so a browser can register Jenkins search.

The full release notes and downloads are on the GitHub release page. The page text is an automatically generated draft for this weekly. The project keeps the edited entries on the official changelog for 2.582.

Trust for update sites is the enhancement in this weekly. #27282 adds a Jenkins project root certificate as a trust anchor, valid from 2026 through 2036. The official changelog calls it preparation for the current root expiring in 2028. The controller checks update center JSON against roots bundled in the WAR. When metadata is later signed with the new root, a controller on this weekly can accept it. An older weekly cannot.

The GitHub draft also deletes the expired root from 2011 through 2021 and rewrites the v2 description so the companion text for the current root matches the new certificate. Files live under war/src/main/webapp/WEB-INF/update-center-rootCAs/. The new anchor is jenkins-update-center-root-ca-2026 plus jenkins-update-center-root-ca-2026.txt. The deleted pair is jenkins-update-center-root-ca and jenkins-update-center-root-ca.txt. The current root certificate file stays. Only jenkins-update-center-root-ca-2.txt is replaced.

No upgrade steps are listed. This weekly does not switch the certificate that signs update center metadata. It adds one trust anchor and drops one that already expired. Controllers that install this WAR load the new root from WEB-INF. Operators who keep an external copy of these roots, for an offline mirror or a signature check outside Jenkins, should add jenkins-update-center-root-ca-2026 before 2028. The 2011 through 2021 root is no longer in the WAR.

Plain text console offsets ¶

#27233 fixes plain text log output dropping trailing partial lines. The official changelog states it as loss of trailing partial lines when tailing plain text console logs. The clients that notice poll a running build at logText/progressiveText with Accept: multipart/form-data.

AnnotatedLargeText.writeLogTo(long, OutputStream) in core/src/main/java/hudson/console/AnnotatedLargeText.java writes through PlainTextConsoleOutputStream, which holds bytes until a newline. Before this weekly the method returned an offset past those held bytes and did not flush them. The tail client stored that offset and resumed there. The fragment stayed in consoleText and disappeared from every later poll.

doProgressTextStreaming calls the non HTML writeLogTo(long, Writer), wraps the writer in WriterOutputStream, and hits the OutputStream overload. That path writes in bulk to the end of the current file instead of stopping at the last newline, so an unfinished line remains buffered. The buffered progressiveText handler sets delegateToWriteLogTo to false and skips this method. Run/_api.jelly documents both routes.

When isComplete() is true, forceEol() flushes the buffer, because that client will not read again. The returned offset is then reduced by lineBufferSize(). A finished build includes the last fragment, and the offset sits at the end of the file. A running build withholds the fragment and the next request starts on it. writeHtmlTo(long, Writer) already adjusted its offset. The plain text overload had not received that change.

AnnotatedLargeTextPartialLineTest covers the contract. A completed log without a final newline must emit the fragment and report the full length. A streaming read of an incomplete log must emit only the last full line and report an offset at that newline. The following read must start with the withheld fragment. Scrapers that pass start back to progressiveText during a build are the clients that change. Reading consoleText after the build ends already returned the full file. A batch step that prints a status token with no newline, then keeps running, was the case that lost the token on the live tail.

#27364 corrects the OpenSearch XML content type and adds moz:SearchForm. The official changelog keeps the user visible result: Jenkins can be added to Firefox using OpenSearch. The report is #27210.

core/src/main/resources/jenkins/model/Jenkins/opensearch.xml.jelly served Content-Type: application/xml. OpenSearch 1.1 requires application/opensearchdescription+xml. Firefox treated the old type as a download. The pull request notes the same rejection in Chrome and Edge. The view now sends the required type, declares the Mozilla namespace, and emits moz:SearchForm set to the Jenkins root URL, which binds the search engine to the controller home page.

SearchTest#testOpenSearchXml checks HTTP 200, the content type, the namespace, and the moz:SearchForm element. The author also ran mvn -pl war hpi:run and opened opensearch.xml in Firefox. No configuration change is required. A site that never hands the descriptor to a browser can ignore the entry. If Firefox rejected it before, retry on this weekly.

One check stays open. A reviewer asked whether opensearch.xml was tried with authentication required. The thread records no later result. On a controller that disables anonymous read, fetch the descriptor before relying on browser registration.