Update Datical fork from jenkinsci fork

.editorconfig

@@ -0,0 +1,11 @@
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+charset = utf-8
+
+[*.{html,java,jelly,xml}]
+indent_style = space
+indent_size = 2

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @jenkinsci/lockable-resources-plugin-developers

.github/copilot-instructions.md

@@ -0,0 +1,114 @@
+# Copilot Instructions — Lockable Resources Plugin
+
+This file tells GitHub Copilot (and other AI assistants) about the project's
+coding standards, PR requirements, and review checklist so they are applied
+automatically when generating code, commit messages, or PR descriptions.
+
+## Project overview
+
+Jenkins plugin that lets builds declare **lockable resources** (printers,
+phones, lab machines, etc.). If a resource is already locked, the build waits
+until it is free.
+
+- Language: **Java 17+** (Maven build, Jenkins HPI packaging)
+- Localization: managed via [Crowdin](https://crowdin.jenkins.io/lockable-resources-plugin); all strings live in `*.properties` files
+- UI examples: documented under `src/doc/examples/`
+
+## Issue linking
+
+- Reference a Jira issue as `JENKINS-XXXXX` with a link to `https://issues.jenkins.io/browse/JENKINS-XXXXX`.
+- Reference a GitHub issue as `#XXXXX`.
+- Use closing keywords (`Fixes #XXXXX`) when the PR fully resolves an issue.
+- Minor improvements do not require a tracking issue.
+- Bug fixes **should** have a tracking issue to facilitate backporting.
+- Major new features **must** have a tracking issue.
+
+## Commit & PR title conventions
+
+- The PR title is used as the **changelog entry** — write it in imperative mood
+  (e.g. "Add timeout parameter to lock step").
+- Follow the style of https://github.com/jenkins-infra/jenkins.io/blob/main/content/_data/changelogs/weekly.yml
+
+## Coding rules
+
+| Area | Rule |
+|------|------|
+| Internal-only public API | Annotate with `@NoExternalUse`; if called from Jelly, add `Used by {@code <panel>.jelly}` Javadoc |
+| New public classes/fields/methods | Annotate with `@Restricted` or add `@since TODO` Javadoc |
+| Deprecations | Use `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")` |
+| JavaScript | No inline scripts, no `eval()` — support future CSP directives (see [docs](https://www.jenkins.io/doc/developer/security/csp/)) |
+| Localizations | Always use `*.properties` files; English strings are mandatory for every new key |
+
+## Testing requirements
+
+- Every change **must** have automated tests, or the PR must explain why tests
+  are not feasible.
+- A green CI build alone does not prove the changed lines were executed —
+  describe the test scenario if coverage is missing.
+- Frontend changes: include before/after screenshots.
+- Refactoring: exercise the code before and after and confirm identical behavior.
+
+## PR labels (automatic)
+
+PRs are auto-labeled by two workflows:
+
+### File-based labels (`actions/labeler`)
+
+| Label | Paths |
+|-------|-------|
+| `java` | `src/main/java/**` |
+| `tests` | `src/test/**` |
+| `ci` | `.github/workflows/**`, `Jenkinsfile` |
+| `dependencies` | `pom.xml` |
+| `documentation` | `*.md`, `src/doc/**` |
+| `localization` | `src/main/resources/**/*.properties` |
+| `frontend` | `src/main/webapp/**`, `src/main/resources/**/*.jelly` |
+| `chore` | `.github/**`, `.gitignore`, `crowdin.yml` |
+
+### Release-drafter labels (`auto-label-pr.yml`)
+
+Added based on PR title/branch (for changelog generation):
+
+| Label | Trigger (title/branch) |
+|-------|------------------------|
+| `breaking` | Title contains "breaking" or "!:" |
+| `major-enhancement` | Title contains "major" + "feat/enhancement" |
+| `major-bug` | Title contains "major" + "fix/bug" |
+| `deprecated` | Title contains "deprecat" |
+| `removed` | Title contains "remove" |
+| `enhancement` | Title starts with "feat"/"add" or branch `feature/*` |
+| `bug` | Title starts with "fix" or branch `fix/*` |
+| `documentation` | Title starts with "docs" or branch `docs/*` |
+| `chore` | Title starts with "chore"/"ci:"/"build:" |
+| `refactor` | Title starts with "refactor" |
+| `security` | Title contains "security"/"cve-" |
+
+### Auto-approve countdown (owner/member PRs)
+
+For PRs by OWNER, MEMBER, or COLLABORATOR (non-draft), the label `merge-in-3-days-without-review`
+is automatically added to start the auto-approve countdown.
+
+## Dependency updates
+
+- Include links to external changelogs and, if possible, full diffs.
+- For new APIs or extension points, link to at least one consumer.
+
+## Upgrade guidelines
+
+- Only needed for breaking changes or changes requiring manual user action.
+- When applicable, set the `upgrade-guide-needed` label.
+
+## Maintainer merge checklist
+
+Before marking `ready-for-merge`:
+
+1. At least **one approval** with no outstanding change requests.
+2. All conversations resolved (or reviewer explicitly not blocking).
+3. PR title is an accurate, imperative-mood changelog entry.
+4. Correct release-drafter labels are set (see [label config](https://github.com/jenkinsci/.github/blob/ce466227c534c42820a597cb8e9cac2f2334920a/.github/release-drafter.yml#L9-L50)).
+5. Java code changes are covered by automated tests.
+
+## Interface changes
+
+Document any UI or pipeline-DSL changes as examples under
+[src/doc/examples/](src/doc/examples/readme.md).

.github/copilot-pr-review-rules.md

@@ -0,0 +1,134 @@
+# Copilot Instructions — PR Review & Cleanup Rules
+
+This file defines the mandatory checklist Copilot must follow when reviewing,
+cleaning up, or triaging pull requests in this repository.
+
+> **Context:** This plugin is large, old, and highly complex. Regressions and
+> performance degradation are real risks. Every PR review must account for
+> testing depth and runtime impact — not just correctness.
+
+## PR review workflow
+
+When asked to review or clean up a PR, always follow these steps **in order**:
+
+### 1. Validate PR description
+
+- Read the PR title and body.
+- Verify the description accurately reflects the actual code changes.
+- Flag mismatches: wrong description, copy-paste errors, or stale text from
+  a template that was not filled in.
+
+### 2. Validate linked items
+
+- Check linked issues (Jira `JENKINS-XXXXX` or GitHub `#XXXXX`).
+- Confirm the linked issue matches the intent of the PR.
+- Flag PRs that reference an unrelated or wrong issue.
+- Minor improvements may omit an issue; bug fixes and features must have one.
+
+### 3. Validate the implementation
+
+- Review the diff: does the code change actually solve the described problem?
+- Look for incomplete changes, dead code, debug leftovers, or unrelated edits
+  that got mixed in.
+- Ensure new code follows the project coding rules (see `copilot-instructions.md`).
+
+### 4. Review all comments — open AND closed
+
+- **Open comments** must be resolved or explicitly accepted with a meaningful
+  response before the PR can be merged. No open comment may be ignored.
+- **Closed / resolved comments** should be read for context — they reveal
+  prior reviewer concerns, rejected approaches, and design decisions.
+
+### 5. Propose a continuation plan
+
+After reviewing the PR state, always provide **at least one concrete proposal**
+for how to move the PR forward. This should include:
+
+- What is missing or broken and what needs to change.
+- Specific next steps (code changes, rebases, comment resolutions).
+- Whether the PR should be continued, split, or closed in favour of a fresh PR.
+- If the PR has been idle for a long time, assess whether the approach is still
+  viable given the current state of `master`.
+
+### 6. Define testing — manual AND automated
+
+Testing is **mandatory** for every non-trivial change. The plugin is complex
+and regressions are costly. Always provide:
+
+#### Manual testing steps
+
+- Describe concrete steps to verify the change locally:
+  ```
+  mvn hpi:run
+  # then in Jenkins UI → Lockable Resources → ...
+  ```
+- Include expected outcomes (what the user should see / not see).
+- For lock/unlock logic changes, describe multi-job concurrency scenarios.
+- For UI changes, list which pages to check and what to look for.
+
+#### Automated testing requirements
+
+- **Unit tests** (`src/test/java/...`) for any new or changed logic.
+- **Integration tests** using `JenkinsRule` for pipeline-level behaviour.
+- **Configuration-as-Code tests** (`ConfigurationAsCodeTest`) when config
+  structures change.
+- If the PR lacks tests, write them or explain precisely why they cannot be
+  added — "no tests" without justification is not acceptable.
+- Run the full test suite before approving:
+  ```
+  mvn clean verify
+  ```
+- If tests are flaky or slow, note it — do not silently skip them.
+
+### 7. Evaluate performance impact
+
+This plugin manages shared resources under contention. Performance matters.
+
+- **Lock/unlock hot paths:** Changes to `LockableResourcesManager`,
+  `LockStepExecution`, or queue handling must be evaluated for:
+  - Lock contention and synchronization overhead
+  - Iteration over all resources (O(n) scans)
+  - Unnecessary save/persist calls (`save()` triggers disk I/O)
+- **Memory:** Watch for resource leaks, unbounded collections, or retained
+  references to `Run` / `FlowNode` objects.
+- **Scalability:** Consider behaviour with 100+ resources and 50+ concurrent
+  builds waiting for locks.
+- If a change affects a hot path, request or write a benchmark scenario:
+  ```java
+  // Example: time lock acquisition with N resources and M waiters
+  ```
+- Flag any change that adds `synchronized` blocks, new `save()` calls, or
+  full-collection scans without justification.
+
+### 8. Update the source branch
+
+- The source branch **must** be up-to-date with the target before merge.
+- If the branch is behind, rebase or merge the target into the source branch
+  first.
+- Never merge a PR with an outdated source branch.
+
+### 9. Target branch rules
+
+- The default target branch is **`master`**.
+- A different target branch is only acceptable for long-running feature
+  development branches (explicitly agreed upon beforehand).
+- If the target branch looks wrong, flag it immediately.
+
+## Summary checklist
+
+Use this quick checklist when processing any PR:
+
+```
+[ ] Description matches the actual changes
+[ ] Linked issue (if any) is correct and relevant
+[ ] Implementation solves the described problem
+[ ] No unrelated changes mixed in
+[ ] All open comments resolved or explicitly accepted
+[ ] Closed comments reviewed for context
+[ ] Continuation plan proposed (next steps / split / close)
+[ ] Manual testing steps documented
+[ ] Automated tests present or justified absence
+[ ] Performance impact evaluated (hot paths, sync, save, memory)
+[ ] Source branch is up-to-date with target
+[ ] Target branch is master (or justified exception)
+```

.github/dependabot.yml

@@ -0,0 +1,12 @@
+# https://help.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
+
+version: 2
+updates:
+  - package-ecosystem: "maven"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"

.github/labeler.yml

@@ -0,0 +1,44 @@
+# .github/labeler.yml — actions/labeler v5 schema
+# Labels PRs based on changed files.
+# For release-drafter compatibility, see also: auto-label-pr.yml
+
+# ═══════════════════════════════════════════════════════════════════
+# File-based labels (auto-applied by actions/labeler)
+# ═══════════════════════════════════════════════════════════════════
+
+java:
+  - changed-files:
+      - any-glob-to-any-file: 'src/main/java/**'
+
+tests:
+  - changed-files:
+      - any-glob-to-any-file: 'src/test/**'
+
+ci:
+  - changed-files:
+      - any-glob-to-any-file: '.github/workflows/**'
+      - any-glob-to-any-file: 'Jenkinsfile'
+
+dependencies:
+  - changed-files:
+      - any-glob-to-any-file: 'pom.xml'
+
+documentation:
+  - changed-files:
+      - any-glob-to-any-file: '*.md'
+      - any-glob-to-any-file: 'src/doc/**'
+
+localization:
+  - changed-files:
+      - any-glob-to-any-file: 'src/main/resources/**/*.properties'
+
+frontend:
+  - changed-files:
+      - any-glob-to-any-file: 'src/main/webapp/**'
+      - any-glob-to-any-file: 'src/main/resources/**/*.jelly'
+
+chore:
+  - changed-files:
+      - any-glob-to-any-file: '.github/**'
+      - any-glob-to-any-file: '.gitignore'
+      - any-glob-to-any-file: 'crowdin.yml'

.github/workflows/auto-approve-owner-prs.yml

@@ -0,0 +1,32 @@
+# Auto-approve owner PRs that receive no review within 3 days.
+#
+# Uses the reusable action: https://github.com/mPokornyETM/auto-approve-stale-prs
+#
+# Countdown labels give reviewers clear visibility:
+#   Day 0 → merge-in-3-days-without-review
+#   Day 1 → merge-in-2-days-without-review
+#   Day 2 → merge-in-1-day-without-review
+#   Day 3 → approved + merged-without-review (auto-merge takes over)
+#
+# Only PRs authored by a repo OWNER or MEMBER are processed.
+# PRs that already have at least one approval are skipped.
+name: Auto-approve owner PRs
+
+on:
+  schedule:
+    - cron: "0 8 * * *" # daily at 08:00 UTC
+  workflow_dispatch: # allow manual trigger
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  countdown:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: mPokornyETM/auto-approve-stale-prs@v1
+        with:
+          days-until-approve: '3'
+          author-associations: 'OWNER'
+          merge-method: 'squash'