This repository was archived by the owner on Feb 10, 2026. It is now read-only.
Update Datical fork from jenkinsci fork - #3
Open
SteveDonie wants to merge 1342 commits into
Open
SteveDonie wants to merge 1342 commits into
SteveDonie wants to merge 1342 commits into
Conversation
…din/github-action-2.2.0 Bump crowdin/github-action from 2.1.2 to 2.2.0
Bumps [io.jenkins.tools.bom:bom-2.440.x](https://github.com/jenkinsci/bom) from 3387.v0f2773fa_3200 to 3413.v0d896b_76a_30d. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.440.x dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…ols.bom-bom-2.440.x-3413.v0d896b_76a_30d Bump io.jenkins.tools.bom:bom-2.440.x from 3387.v0f2773fa_3200 to 3413.v0d896b_76a_30d
Bumps [io.jenkins.tools.bom:bom-2.440.x](https://github.com/jenkinsci/bom) from 3413.v0d896b_76a_30d to 3435.v238d66a_043fb_. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.440.x dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…ols.bom-bom-2.440.x-3435.v238d66a_043fb_ Bump io.jenkins.tools.bom:bom-2.440.x from 3413.v0d896b_76a_30d to 3435.v238d66a_043fb_
…Lock` now that running builds may not be deleted (#716) * [JENKINS-73835] Adjust LockStepTest.killThenDeleteRunningBuildNewBuildClearsLock now that running builds may not be deleted * [JENKINS-73835] Just delete test instead, LockStepHardKillTest already covers WorkflowRun.doKill * Format with spotless --------- Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
…RootAction/tableResources/table.jelly` (#720)
…Action/tableQueue/table.jelly` (#719)
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.2.0 to 2.3.0. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.2.0...v2.3.0) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…din/github-action-2.3.0 Bump crowdin/github-action from 2.2.0 to 2.3.0
The Jenkins plugin archetype uses jenkins.baseline to prevent inconsistencies between the minimum required Jenkins version and the Jenkins plugin bill of materials version. Use the same technique in this plugin.
This relates to #198
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.4.0 to 2.5.0. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.4.0...v2.5.0) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.479.x](https://github.com/jenkinsci/bom) from 3893.v213a_42768d35 to 3944.v1a_e4f8b_452db_. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.479.x dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…ols.bom-bom-2.479.x-3944.v1a_e4f8b_452db_ Bump io.jenkins.tools.bom:bom-2.479.x from 3893.v213a_42768d35 to 3944.v1a_e4f8b_452db_
Bumps [io.jenkins.tools.bom:bom-2.479.x](https://github.com/jenkinsci/bom) from 3944.v1a_e4f8b_452db_ to 4023.va_eeb_b_4e45f07. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.479.x dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…ols.bom-bom-2.479.x-4023.va_eeb_b_4e45f07 Bump io.jenkins.tools.bom:bom-2.479.x from 3944.v1a_e4f8b_452db_ to 4023.va_eeb_b_4e45f07
Bumps [org.jenkins-ci.plugins:plugin](https://github.com/jenkinsci/plugin-pom) from 5.5 to 5.6. - [Release notes](https://github.com/jenkinsci/plugin-pom/releases) - [Changelog](https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md) - [Commits](jenkinsci/plugin-pom@plugin-5.5...plugin-5.6) --- updated-dependencies: - dependency-name: org.jenkins-ci.plugins:plugin dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.5.1 to 2.5.2. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.5.1...v2.5.2) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
…i.plugins-plugin-5.6 Bump org.jenkins-ci.plugins:plugin from 5.5 to 5.6
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6549.v96f8c826373f to 6585.va_085f4d47c41. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6585.va_085f4d47c41 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.16.2 to 2.16.3. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.16.2...v2.16.3) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 2.16.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v6...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6585.va_085f4d47c41 to 6607.v3ed3d8ddfed8. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6607.v3ed3d8ddfed8 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6607.v3ed3d8ddfed8 to 6641.vfe1b_b_3c48a_4a_. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6641.vfe1b_b_3c48a_4a_ dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* fix: include build parameters in script-match cache key The per-resource Groovy script-match result cache (added in #966) keyed only on the script text, ignoring the parameter bindings passed into the script's evaluation. When several jobs share an identical match script and differ only by build parameters — a common pattern where the resource to lock is chosen by a parameter, e.g. `resourceName == TARGET_ENVIRONMENT` — the first job's per-resource results are cached and wrongly reused for every other job. Each subsequent job is told it matches the first job's resource (already locked) and blocks, so the jobs serialise behind a single resource instead of each locking its own free resource, for the duration of the cache TTL (default 30s). Fix: build the cache key from the script text plus a deterministic encoding of the parameter bindings, so evaluations with different parameters are cached separately. Adds a regression test (scriptResourceJobsRunConcurrently) submitting N jobs that share one parameter-driven match script; it asserts they run concurrently (peak concurrency N) rather than serialising to one at a time. Fails without this change, passes with it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test: make scriptResourceJobsRunConcurrently reliable on slow Windows CI Reduce N from 12 to 5: still distinguishes serial dispatch (peak=1) from concurrent dispatch (peak=N), but needs fewer concurrent JenkinsRule builds and therefore less memory/scheduling headroom. Extend timeouts to match observed Windows agent slowness: - allStarted latch: 20s → 60s - build completion: 30s → 60s - build hold (release latch): 30s → 90s Windows CI agents took ~10 min total in the failing run; the 20s latch was too tight for N=12 builds to all start concurrently. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
…controller (#1055) * Remote Lockable Resources (issue #1025 phase 1) Allow a pipeline lock() to target a resource owned by a different Jenkins controller, over a versioned REST API, with the same lock() semantics as a local lock. Client side: - lock(serverId: 'X') selects a configured remote (peer mode); a controller-wide forcedServerId transparently delegates every lock (delegated mode). - RemoteLockSession drives acquire -> short-poll -> heartbeat -> release; fail-closed on transport errors; poll/heartbeat timers are transient and rebuilt on controller restart. Server side: - REST API under /lockable-resources/remote/v1 (acquire / status / heartbeat / release), guarded by a dedicated RemoteUse permission. - RemoteResolver performs admission (existence/exposure via exposeLabel) and resolves through the canonical getAvailableResources path; the server never re-implements lock() semantics. - Remote requests share the local priority queue; STALE leases (missed heartbeats) can be force-released from the dashboard. Configuration (global): remote connections (serverId/url/credentials), exposeLabel, clientId, forcedServerId. See #1025 for the phase plan and design. * Fix code formatting to satisfy spotless:check (CI) * Fix SpotBugs findings to satisfy the CI quality gate * Address Jenkins Security Scan findings on the remote API Resolve the four code-scanning alerts raised on PR #1055: - doCheckUrl (alerts 49/51): require POST and check ADMINISTER. - doCheckForcedServerId (alert 50): require POST (ADMINISTER was already checked). Both form fields gain checkMethod="post". - GET /acquire/{lockId} (alert 52): make it a pure read. Drop the poll-keepalive side effect (touchPoll); QUEUED entries now expire solely through the unified queue timeout (RemoteQueueEntry deadline), which already owns their lifecycle. * Report a remote acquire timeout as LOCK_WAIT_TIMEOUT, not a 404 failure A queued remote acquire that exceeds timeoutForAllocateResource is marked FAILED (LOCK_WAIT_TIMEOUT) and retained so the polling client can read the terminal state. The terminal-record TTL was measured from the enqueue time, so when timeoutForAllocateResource exceeded the 120s TTL the FAILED record was already past its retention the instant it was created and got evicted on the next maintenance pass. The client's next GET /acquire poll then received HTTP 404 and failed closed as a communication failure, mislabeling a legitimate allocation timeout as a transport error. Measure the terminal-record TTL from when the record becomes terminal (new terminalAt timestamp set in markFailed/markSkipped) instead of from enqueue, so a FAILED/SKIPPED record is always observable for the full TTL regardless of how long the queue wait was. As a safety net, normalize a poll 404/410 received before the body starts to LOCK_WAIT_TIMEOUT on the client. Surfaced by high-load testing with an allocate timeout (3 minutes) larger than the terminal-record TTL. * spotles * Fix remote config help links returning 404 (Not Found) The explicit help= paths used a hyphen (help-fieldName) instead of the slash form (help/fieldName) that Descriptor#getHelpFile actually generates, so Stapler couldn't resolve them and every (?) popup under the Remote Lockable Resources server/client config sections showed "Failed to load help file: Not Found". * Remote LR UX follow-up: credentials selector, better diagnostics, heldBy column - RemoteConnection: replace free-text credentialsId with Jenkins credentials dropdown (doFillCredentialsIdItems using ACL.SYSTEM2 for system store lookup) - RemoteConnection/config.jelly: fix help link paths to descriptorByName - help-credentialsId.html: document API token requirement and CSRF behavior when plain password is used - RemoteApiClient: preserve HTTP errors without rewrapping as communication failure; enrich error messages with remote errorCode/message; add actionable hint for 404 (wrong base URL / resource not exposed) - RemoteLockSession: include serverUrl in pipeline log messages; print human-readable error to build log on acquire failure - LockableResource: add getRemoteLockRecord() accessor for Jelly views - tableResources/table.jelly: populate heldBy column for remote locks with clientId (requesting controller) and requested resource/label - tableResources/table.properties: add resource.heldBy.remoteUnknown key - RemoteApiClientTest: add regression test for 404 diagnostics * docs: add Remote Lock REST API curl examples Covers: acquire by resource/label, poll loop, heartbeat in background, release, skipIfLocked, timeout, full API reference table, credentials note. * more docs * more things * other findings * fix: restore LockableResource.java to LF and fix null-byte corruption in char literal --------- Co-authored-by: kohtaro-satoh <e176@cs-atelier.co.jp> Co-authored-by: Martin Pokorny <martin.pokorny@etm.at> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
Co-authored-by: Benjamin Meeusen <benjamin.meeusen@septentrio.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6641.vfe1b_b_3c48a_4a_ to 6687.v4253d9799d33. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6687.v4253d9799d33 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [actions/labeler](https://github.com/actions/labeler) from 6 to 7. - [Release notes](https://github.com/actions/labeler/releases) - [Commits](actions/labeler@v6...v7) --- updated-dependencies: - dependency-name: actions/labeler dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.16.3 to 2.17.0. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.16.3...v2.17.0) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 2.17.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6687.v4253d9799d33 to 6783.v88c6c30f4b_db_. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6751.v745d6a_31066a_ dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [org.jenkins-ci.plugins:plugin](https://github.com/jenkinsci/plugin-pom) from 6.2189.v695a_c41f5249 to 6.2211.v27f680c93c53. - [Release notes](https://github.com/jenkinsci/plugin-pom/releases) - [Changelog](https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md) - [Commits](https://github.com/jenkinsci/plugin-pom/commits/6.2211.v27f680c93c53) --- updated-dependencies: - dependency-name: org.jenkins-ci.plugins:plugin dependency-version: 6.2211.v27f680c93c53 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
* Sync missing localization keys for translated bundles (#971) * Add German translations for missing message keys * missing translations
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6783.v88c6c30f4b_db_ to 6815.v1fb_2a_fee3765. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6815.v1fb_2a_fee3765 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6815.v1fb_2a_fee3765 to 6904.v75208ee5a_206. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6904.v75208ee5a_206 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [org.jenkins-ci.plugins:plugin](https://github.com/jenkinsci/plugin-pom) from 6.2211.v27f680c93c53 to 6.2221.va_045130417c9. - [Release notes](https://github.com/jenkinsci/plugin-pom/releases) - [Changelog](https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md) - [Commits](https://github.com/jenkinsci/plugin-pom/commits) --- updated-dependencies: - dependency-name: org.jenkins-ci.plugins:plugin dependency-version: 6.2221.va_045130417c9 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6904.v75208ee5a_206 to 6916.v15ec97679743. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6916.v15ec97679743 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.17.0 to 2.17.1. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.17.0...v2.17.1) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 2.17.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 2.17.1 to 3.0.0. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v2.17.1...v3.0.0) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 3.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6916.v15ec97679743 to 6931.vea_a_b_c6fd017d. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6931.vea_a_b_c6fd017d dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6931.vea_a_b_c6fd017d to 6967.v7a_6959124326. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 6967.v7a_6959124326 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 3.0.0 to 3.0.2. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v3.0.0...v3.0.2) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 3.0.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
The lock() step and freestyle builds only exported per-resource property environment variables under the numeric index form (e.g. LOCKED_RESOURCE0_PROP_ABC), even for a single-resource lock. This adds a non-indexed alias (LOCKED_RESOURCE_PROP_ABC) that always points to the first locked resource's property, matching the existing behavior of the plain LOCKED_RESOURCE variable. This is additive and non-breaking: all existing indexed variables are unchanged. Fixes #526 Claude-Session: https://claude.ai/code/session_013KP9Eh2FVMDXiiLANSHnJG Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
* [A1] Report the remote holder in the lock cause
A resource held through the remote API has no build and no reserved
timestamp - both live on the remote lock record - so the generic branches
rendered it as "is locked by null at <unknown>". That string reaches the
REST API as lockCause and, more visibly, the console of a job that is
locally waiting for the same resource, which is the first place someone
looks to find out why they are waiting.
Name the holder instead: the client id when the record still knows it,
otherwise the lock id, together with when it was acquired. The detail
form keeps the lock id as well, since that is what correlates the wait
with the remote server's own logs.
getRemoteLockRecord() now resolves the manager defensively. The lock
cause is also rendered outside a running Jenkins, and reaching through
Jenkins.get() from there throws.
Plan: A1 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [A2] Keep a released remote lock until its terminal TTL
Releasing dropped the record from the map straight away, so a status poll
arriving right behind the release got a 404 - the same answer as "this
server restarted and never heard of your lock". The client cannot tell
the two apart, and the 404 is what the poll loop treats as irrecoverable.
Mark the record terminal instead and let the existing TTL sweep remove
it, which is already how a failed or skipped request is retired. A
GET then reports FAILED / RELEASED for the next two minutes.
Because the record now outlives the release, a repeated or late release
has to be a no-op: it would otherwise free whatever holds the resource by
then, which may be somebody else's lock.
Plan: A2 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [A3] Report a vanished remote lock record as missing, not as a timeout
The poll loop split its 404/410 handling on whether the body had started,
reporting a still-acquiring request as LOCK_WAIT_TIMEOUT. Neither half
matched reality: polling stops the moment the lock is acquired, so the
body-started side was unreachable, and a genuine allocation timeout comes
back as a terminal FAILED state rather than a 404. Releasing a queued
request no longer drops the record either.
What remains is a record that is really gone - the server restarted, the
record outlived its TTL, or the id was never issued here - so say that.
Manufacturing a LOCK_WAIT_TIMEOUT also masked regressions: the E2E guard
for the timeout path looks for that string in the console and would have
stayed green while the server-side path was broken.
Plan: A3 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [A4] Set the remote lock env vars even when the server returns none
X_SERVER_ID and X_LOCK_ID describe the bridge, not the resources, but
they were only injected when the server had also sent lock env vars of
its own. A response without any - nothing to name, or an older server -
left the pipeline without them despite an explicit variable.
Plan: A4 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [A5] Fix the queue tab handling of remote entries
Three ways the tab treated remote rows as second-class:
- The order was "every local entry, then every remote one", which
contradicts promotion: proceedNextContext compares the heads of the two
queues by priority and only favours local on a tie. Concatenating
local-first and stably sorting by descending priority reproduces that
exactly, so a high-priority remote request no longer appears to be
waiting behind locals it will overtake.
- Change Position was offered on remote rows, where it can only fail:
reordering looks the id up among the local queued contexts.
- The free-text filter looked at resource names, labels and build names,
none of which a remote row has, so it could only ever match the lock id.
Plan: A5 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [A6] Enforce the allocate timeout of a queued remote request
A remote request that has to wait computes a deadline from
timeoutForAllocateResource, but nothing ever wakes up to enforce it: the entry
is only examined when a queue maintenance pass runs for some other reason. In
practice that means the holder releasing, so the timeout does not bound the
wait - it fires late, or not at all while the resource stays held. That is the
opposite of what the option is for: a caller asks for a bounded wait precisely
because the resource might be stuck.
The local queue has this covered. queueContext() schedules a wake-up when a new
entry's deadline is earlier than the pending one, and getNextQueuedContext()
reschedules for the earliest remaining deadline. queueRemote() and the remote
scan had no equivalent.
Give the remote queue the same two halves. The second one is not optional:
there is a single timeout task and scheduleTimeoutAt() cancels what is pending
before scheduling again, so computing the deadline from the local queue alone
does not merely ignore remote entries - it cancels the wake-up a remote entry
was relying on and never puts it back.
The existing tests could not see this. They call checkTimeouts() by hand, which
is the maintenance pass production code never schedules, so they exercised the
timeout logic while proving nothing about whether it is reached. The new test
sends a request with a 500ms deadline and then touches nothing: no
checkTimeouts(), no release, the holder keeps holding. Before this change it
was still QUEUED ten seconds later.
* [A7] Reject acquire fields the endpoint cannot interpret
The lock() DSL gets its types from Java. A pipeline cannot pass "abc" where an
int is declared, and setTimeoutUnit refuses a unit that is not a TimeUnit. JSON
offers no such guarantee, and this endpoint reads its fields with optInt,
optLong and optString, so a value it cannot interpret silently becomes the
default rather than being refused.
That is not a milder version of the same behaviour. It changes what the request
means, and always in the direction of doing more:
* a quantity that is not a number becomes 0, and 0 on a label means "every
match" - so a typo asks for the whole pool instead of the one machine;
* a timeout that is not a number becomes 0, and a timeoutUnit that is not a
TimeUnit disables the deadline outright, so a bounded wait quietly becomes
an unbounded one.
Neither is reachable through a local lock(), so both arrived with this endpoint.
Parse strictly and let the caller hear about it.
Strict is not the same as brittle. A numeric string still parses, because
json-lib reads one as a number and clients send them; an explicit null is
treated as absent, because serialisers routinely emit null for an unset field
and refusing those would break callers over nothing. Zero and negative keep
their meanings - both are expressible through a local lock() and mean "no
limit" there.
The same reading applies to the string fields, which had a quieter version of
the problem: optString hands back the four-character string "null" for a JSON
null, so "resource": null went looking for a resource actually named "null" and
"variable": null would have exported an environment variable by that name.
* [B1] Apply inversePrecedence to remotely queued requests
The flag travels on the wire and is kept on the request, but the remote
queue only ever looked at priority, so the parameter that makes a local
lock() take the first position did nothing once the request arrived over
the bridge. queueContext() jumps the queue when inversePrecedence is set
and the priority is the default; queueRemote() now does the same, and
falls back to the ordinary priority insert in the same case local does.
This is not a remote-specific ordering rule. It is a local rule that
never reached the remote path.
Plan: B1 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [B2] Delegate remote request validation to the canonical validator
The REST boundary carried its own copy of two lock() rules, and the copy
had drifted: MISSING_TARGET rejected a request without a target
unconditionally, while a local lock() honours allowEmptyOrNullValues. The
same call therefore behaved differently depending on which side of the
bridge it came from. Two further rules were missing entirely, so the
bridge accepted requests the DSL refuses.
Hand the whole question to LockStepResource.validate() instead, extras
included, and map its IllegalArgumentException to 400 INVALID_REQUEST
with the message a local lock() would have printed. Three things change:
- A target-less request is now accepted when allowEmptyOrNullValues is
on, granting the same no-op lease local gives it.
- resource and label together are rejected (M1E-2, left alone at the time
because closing it meant adding remote-specific code - it now closes by
removing some).
- priority together with inversePrecedence is rejected.
Validation runs after admission, not before. The canonical validator also
rejects labels that do not exist, and answering that with a 400 while an
existing-but-unexposed label answers 404 would tell a client which names
are real; admission has already reduced both to a uniform 404 by then.
The queue-order test for inversePrecedence combined with a priority goes
away with this: the combination is no longer a request one can make.
Plan: B2 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [B3] Add a maintenance switch for the remote acquire endpoint
Requested in #1025: a way to service a server without disturbing the
controllers locking against it. acceptNewAcquires (on by default, next to
the other remote settings and exportable through JCasC) turns only
POST /acquire into a 503 ACQUIRES_PAUSED. Status, heartbeat and release
keep answering, so leases in flight are untouched, and requests already
queued keep their place and are still promoted - the server drains rather
than stranding its clients.
A client that meets the 503 does not fail its build. It says so once and
then keeps asking at the poll interval until its own allocation timeout
expires, which is the behaviour that makes the switch worth having; a
request without a timeout waits indefinitely, as a local lock() would.
If the controller restarts while a step is waiting on a paused server,
the step fails closed. No lock exists anywhere at that point, and the
retry loop does not survive the restart, so the alternative is a build
that waits forever.
The default is expressed as a field initializer, matching
allowEphemeralResources in the same class.
Plan: B3 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [B4] Add the remote resources discovery endpoint
GET /lockable-resources/remote/v1/resources lists what this server
exposes, so a client controller can show the resources it locks against
instead of only the ones it owns. The exposure filter is the existing
exposeLabel set - no second notion of visibility - and the endpoint is
gated exactly like the other four.
Each entry carries the state a local Resources tab shows (FREE, LOCKED,
RESERVED, QUEUED) so both sides of the client page can be read with the
same eye. The original design left state out to keep the response cheap
and cacheable; that made the remote half of the page thin enough to be
useless, so it is in, and the client caches it for seconds rather than a
minute.
Holder information stops at the kind - a local build, a remote client, an
administrator - plus the timestamp, and the client id when a remote
client holds it. Build names, URLs, reasons and notes stay here: the
admin published resources, not the names of the jobs using them, and this
list is rendered on a controller whose viewers may have no account here.
acceptNewAcquires travels in the same response. Split across two
endpoints, two client caches could disagree and the page would offer a
resource the server has already stopped handing out. Resource state stays
truthful while paused; saying "not right now" is the page's job.
Plan: B4 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [B5] Let a client disable a remote without deleting it
There was no way to say "not this server, for now". You either deleted
the connection - losing its credentials binding with it - or broke its
URL on purpose. This is the borrower's counterpart of the maintenance
switch: that one stops lending resources out, this one stops asking.
A lock() naming a disabled connection fails the step. It does not fall
back to a local resource of the same name, for the reason delegated mode
does not either: locking something other than what was asked for is
worse than failing. forcedServerId pointing at a disabled connection now
warns where the "no such server" warning already was, because delegated
mode would otherwise fail every lock() with the explanation only in build
logs.
Locks already held are untouched - heartbeats and releases continue, or
the resources would be stranded on the far side. The Remote tab says
which servers are switched off, so a held entry that never grows a
sibling is not a puzzle.
The field is set through a DataBoundSetter rather than a constructor
argument: configuration written before it existed, JCasC included, has
only the three connection fields and must keep loading. Default true,
from the field initializer.
Plan: B5 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [B6] Record who holds each resource, where it changes hands
Mutual exclusion cannot be reconstructed from the clients, and the load suite has
been trying to. A client can only timestamp its own call to release, and that call
returns after the server has already freed the resource and possibly handed it to
the next waiter - so two clients' logs can show an overlap on a resource that was
never held twice. Nothing in those logs tells that apart from a real double-grant,
which makes the strongest oracle in the suite unable to answer the question it
exists to answer. A recent run reported ten such overlaps, all under a second.
Write one line per state change instead, at the four places a resource actually
changes hands, under the lock that guards it. The order of the lines is then the
order it happened, on one clock, and each line names the holder - the lock id for
a remote hold, the build for a local one - so a client's view can be joined to the
server's rather than substituted for it.
It is a logger of its own, off unless asked for. Turning the manager's logger to
FINE to see holdings would bury them, and ordinary use should not pay for lines
nobody reads: with the logger off this costs one level check.
Not only for tests. "Who held this, and when did they let go" is the question an
operator asks when a resource is stuck, and the answer today is a debug line that
prints a list with toString.
* [C1] Track the remote locks this controller holds or waits for
The client side of a remote lock lives in a session per lock() step,
which runs the step but leaves nobody able to answer "what is this
controller doing remotely right now?" - the question the lockable
resources page answers for local resources. RemoteClientRegistry is the
client-side counterpart of the server's RemoteLockManager, and the data
source for the page work that follows.
It is not persisted. A remote lock does not survive a restart of this
controller - the session either resumes polling or fails closed - so an
entry read back from disk could only be wrong. onResume re-registers what
genuinely survived, which also settles a leftover from M1: a resumed
session used to describe itself by lock id, because the description of
what had been asked for was not kept. It is now.
Entries hold their build weakly and copy its name: the page has to keep
rendering a lock whose build was deleted, and must not be the reason a
finished build stays in memory.
GET /acquire/{lockId} now also reports the resources it handed over.
Without that the client cannot name what it holds - lockEnvVars only
carries the names when the caller asked for a variable - and the page
needs them. The field is additive; older clients ignore it.
Plan: C1 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [C2] Show the remote locks on the lockable resources page
The known limitation of #1055: a controller that acquires locks elsewhere
had nowhere to show it. Its own resources are listed, its queue is
listed, and the locks it holds on other controllers appeared nowhere at
all - the only way to find out was to read a build log.
A Remote tab now lists them, held first, then waiting: which server, what
was asked for, the state, the resources handed over, the build that asked
and how long it has been that way. It opens with a note that this is what
this controller last observed and that the remote is the source of truth
for its own resources; the page cannot honestly claim more than that.
No cancel or release buttons. Phase 1 stops at showing, because a button
here would let someone drop a lock a pipeline still believes it holds.
The tab appears only when a remote relation is configured at all, either
direction - otherwise it is an empty promise.
Two other things had to give. The tab bar was rendered only when this
controller had at least one local resource, and so was the whole tabbed
view; a delegated controller legitimately has none, and would have lost
the tabs it now needs. And with no local resources the page opens on the
Remote tab, since Overview would have nothing to say.
Servers switched off with the connection-level enabled flag are marked as
such here: a held entry that never grows a sibling would otherwise be a
puzzle.
Plan: C2 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [C3] Show the delegated target's resources next to the local ones
In delegated mode every lock() goes to one remote server, and the page
said nothing about it: the resources listed were the local ones, which
are precisely the ones this controller's own locks no longer use.
A badge now names the target, and the Remote tab lists what that target
publishes - name, state, who holds it, labels - above the locks this
controller holds there.
The local resources stay. The original design had them replaced, and this
reverses that: roles are per relation, so a controller that delegates its
own lock() calls can still be the server others lock against, and hiding
its resources would hide the ones they are actively locking. The badge
carries the distinction instead: these are still lockable by other
controllers, they just do not resolve this controller's own lock() calls
any more.
The catalog is cached for ten seconds and never fetched while rendering.
A page render serves whatever snapshot exists and asks for a refresh in
the background, so a slow or unreachable server costs an age indicator
rather than a page that hangs - display is best-effort, while acquiring
a lock stays fail-closed. A failed refresh keeps the previous snapshot
and says so rather than blanking the table.
Ten seconds rather than the minute originally planned: the response now
carries live state and whether the server is accepting new acquires, and
a minute-old copy of that would be shown as though it were current.
Disabled connections are not contacted at all, which is what disabling
one means, and changing the remote configuration drops every snapshot.
Plan: C3 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [C4] Show a banner while new remote acquires are paused
The maintenance switch is easy to leave on, and from this side its effect
is invisible: clients wait quietly instead of failing, so nothing here
looks wrong while nothing is being handed out either. The page now says
so, and says what it means - held locks keep working, clients are
waiting - along with where to turn it back on.
Only while the remote API is enabled. With it off nothing is being served
at all, and a banner about paused acquires would be noise.
Plan: C4 in dev/docs-j/ph1-ms2/implimentation_plan.md (Phase 1 M2+M3).
* [T1] Let the test remote server be scripted
The client half of a remote lock is a state machine driven by what a server says
over time: a request that queues and is later promoted, one that ends in a
terminal state, a lease that goes stale, a server that stops answering for a
while. None of that can be provoked from the client side, and a real server will
not produce those states on demand either - it produces the ones its own state
warrants.
The fixture the remote tests already use could say two things: acquired, and the
maintenance switch's 503. That is why the paths around the others are the least
covered code in the plugin.
Extract it from the test class it was nested in and give it a script: queue for
n polls before acquiring, end in a terminal state with an error code, fail the
next n status polls, answer heartbeats with a status of the test's choosing,
serve the resources endpoint, and restart on the same port so a client can be
made to resume against the address it already has.
No test changes here beyond the move - the existing ones pass unmodified, which
is the point of doing this separately.
* [T2] Cover what the client does with the answers it gets
The happy path was covered: ask, be told it is yours, run the body. Everything
after that was not, and it is most of the client's state machine - the branch
coverage of RemoteLockSession stood at a third.
Eight cases, each ending somewhere a build can see:
* queued for a while, then promoted - the body must not start until it is
actually held;
* a terminal FAILED with LOCK_WAIT_TIMEOUT - fails closed, body never runs;
* a terminal SKIPPED - the body is skipped and the build carries on, which is
the whole difference between skipIfLocked and a failure;
* a 404 and a 410, both reported as a record the server no longer has rather
than as a timeout, which is the mislabelling A3 was about;
* a few failed polls, ridden out - giving up here would fail builds over a
server that was briefly busy;
* polls that never recover, which must end the build rather than hang. This
one takes about a minute because the poll interval and the failure count are
both fixed, and it is the only threshold at which the client gives up alone;
* a heartbeat refused with 410, which must not interrupt a running body - the
server holds the lease until STALE, so aborting would discard work the build
still owns.
* [T3] Cover what a restart does to a remote lock
onResume had no coverage at all - not from the unit tests, and not from the E2E
or load suites either, because the only controller any of them restarts is the
server. Forty lines and twelve branches of the path that decides what happens to
a lock held on another machine when this one goes down.
It matters more than a local restart does. The server knows nothing about this
controller going away, so the two sides can disagree in a way a local lock
cannot: a resource held for a build that no longer exists, recoverable only by an
administrator.
Three cases, one per branch:
* still queued - the resumed step has to pick the poll back up. Letting the
server hand the resource over afterwards is what proves it did; nothing else
would ever ask again;
* holding, body running - the body dies with the controller, so the lock has to
go back. This is the one that would strand a resource;
* waiting on a paused server - there is no lock anywhere, and the retry loop did
not survive. Failing is the honest outcome; waiting forever for a retry that
will never come is worse than saying so.
The fixture restarts on its own port, so the resumed controller finds the remote
where its configuration says it is. On a new port the test would only prove that
a client cannot reach a server that moved.
No production change: all three behaved as written.
* [T4] Cover reading another controller's catalogue
listResources had no branch coverage at all, and it is the one client call whose
job is to be tolerant: the page it feeds is best-effort, unlike acquiring a lock.
Five cases. The parsing has to survive a server that omits fields - an older one,
or one that grew acceptNewAcquires later - and treat its absence as "not paused"
rather than as "paused". An empty catalogue is a legitimate answer, not a fault.
The two failures are the point. A 403 or an unreachable server has to arrive as
an exception, because the cache's fallback depends on telling that apart from an
empty list: read as a catalogue, both would render as "this server publishes
nothing", which is a different and wrong statement about the remote.
* [T5] Cover the routing decisions and the stale catalogue view
Three small things that decide a lot.
Routing decides whether a lock is remote and whose it is, and getting it wrong is
not a visible failure - it is a build locking the wrong controller's resource, or
locking locally what it was meant to borrow. The delegated-mode override is the
sharp edge, so it is checked from both sides: a controller that delegates
overrides the serverId a pipeline named, and a blank setting is not a server.
State parsing decides what happens when a newer server reports something this
client has never heard of. UNKNOWN is treated as a failure, so the build stops
rather than continuing against a lock nobody here can describe; throwing instead
would turn a forwards-compatible server into a broken one.
The catalogue cache already had a test for failing with nothing cached. The
branch that matters is the other one - a remote that answered once and then
stopped - because that is where the page either keeps what it knew or starts
claiming the server publishes nothing.
* [T6] Drop a remote lock record accessor nothing calls
getResourceName has had no callers since it arrived with #1055 - not in the
plugin, not in the views, not in the tests. It showed up while reading a coverage
report, as four lines and four branches that nothing reaches.
Removing it is the honest response. Writing a test for it would have raised the
number while leaving the code exactly as unused as it was, and left a reader to
wonder which caller they had failed to find.
getAcquiredResourceNames, which callers do use, is untouched.
* [D1] Document the remote lockable resources feature in the README
The README said nothing about remote locking - not the step argument, not the
configuration on either side, not the permission that gates the API. The
feature shipped in #1055 and is reachable only by reading the code or the curl
examples, which is not where an administrator looks first.
Describe it from the outside in: what problem it solves, the one extra argument
on lock(), and then what has to be configured on the server and on the client.
Two behaviours get stated explicitly because getting them wrong is expensive.
Expose label is empty by default, so enabling the API on its own exposes
nothing. And a lease whose heartbeats stop is marked STALE but never released
automatically - a quiet client may still be driving the hardware.
Add the RemoteUse row the permissions table was missing, and a JCasC example
for the remote keys alongside the existing one.
While here, note that the combined variable joins resource names with commas,
so splitting it is only safe while no name contains one. The existing example
does exactly that split; the numbered variables are the reliable form.
* [D2] Correct the remote API reference for the shipped behaviour
The reference described an earlier shape of the API, and the gaps are the kind
that cost a caller a debugging session rather than a glance at the page.
States: EXPIRED does not exist and never comes back from the server; STALE does
and was missing. Say what happens to a terminal record after 120 seconds, so a
poller that gets a 404 knows it did not lose its lock.
Errors: the table listed MISSING_TARGET, which B2 folded into INVALID_REQUEST
when validation moved to the canonical validator, and stopped there. List what
the endpoint actually returns, including INVALID_FIELD_VALUE for values it
refuses to guess at, and the 503 that says the server is draining rather than
broken.
Heartbeat: the interval is the server's, not the caller's -
heartbeatIntervalSeconds is validated and then ignored. And a stale lease is
not auto-released, which is the opposite of what a reader would assume from
"an admin can force-release it".
inversePrecedence is applied now (B1), so stop telling callers to work around
it. Add the GET /resources endpoint, which had no entry at all, and note what
it deliberately leaves out.
* [B7] Annotate the remote resources endpoint with GET
The Jenkins security scan reports ResourcesResource#doIndex as a possible CSRF
risk: with no verb annotation Stapler routes any HTTP method to it, so a
state-changing or expensive handler would be reachable from a cross-site POST.
This one is read-only - it lists what the server exposes and changes nothing -
so the fix is to say that rather than to require POST. #1076 resolved the same
finding on the acquire status endpoint next door the same way; the test mirrors
the one it added, so the annotation cannot quietly go missing again.
* [B8] Fix the unresolvable javadoc reference in RemoteResolver
The linux CI lane fails at `javadoc:jar`, not in the tests: RemoteResolver
sits in the .remote package and does not import LockStep, so
{@link LockStep#validate} cannot be resolved and javadoc exits 1.
Fully qualified rather than imported. LockStep appears in this file only in
two javadoc comments and never in code, so an import would be an unused one.
Reproduced and verified locally with `mvn javadoc:javadoc`: exit 1 with
"reference not found" before, BUILD SUCCESS after. It is not JDK-specific -
CI's linux lane is on JDK 25 and this reproduces on 21.
Worth recording why it reached CI at all: our local gate runs `mvn clean
verify`, and maven-javadoc-plugin never runs in that lifecycle. The gate had
no way to see this. That is fixed separately in the harness.
* Empty commit to rerun test
---------
Co-authored-by: kohtaro-satoh <e176@cs-atelier.co.jp>
Co-authored-by: Martin Pokorny <89339813+mPokornyETM@users.noreply.github.com>
Bumps [io.jenkins.tools.bom:bom-2.541.x](https://github.com/jenkinsci/bom) from 6967.v7a_6959124326 to 7002.v028a_3607ddc8. - [Release notes](https://github.com/jenkinsci/bom/releases) - [Commits](https://github.com/jenkinsci/bom/commits) --- updated-dependencies: - dependency-name: io.jenkins.tools.bom:bom-2.541.x dependency-version: 7002.v028a_3607ddc8 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 3.0.2 to 3.1.0. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v3.0.2...v3.1.0) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 3.1.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [crowdin/github-action](https://github.com/crowdin/github-action) from 3.1.0 to 3.3.0. - [Release notes](https://github.com/crowdin/github-action/releases) - [Commits](crowdin/github-action@v3.1.0...v3.3.0) --- updated-dependencies: - dependency-name: crowdin/github-action dependency-version: 3.3.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.