[uniqueg]

Summary

Release prep for tesk-api 1.3.0: TES 1.1 fields (including ignore_error), filters, states and output file logs; tokens of allow-listed service clients; experimental private executor images; Java 21 and the resource server of Spring Security. The FI TESK needs #154 (service client tokens) so that a TES gateway can call it with its client-credentials token; the TESK chart (elixir-cloud-aai/TESK#299) then needs this version.

• pom.xml, CITATION.cff (version: "1.3.0", date-released: "2026-11-16", the planned tag date) and the built-in service-info.yaml (version: 1.3.0).
• docs/releases/1.3.0.md: curated release notes in the organisation's format (the release workflow appends GitHub's generated notes under ## Commits and the **Full Changelog** line). Since the first version of this PR, dev was merged in (merge commit, no rebase) and the notes cover build: move to Java 21 #161 (Java 21), feat: support executors[].ignore_error #174 (ignore_error), refactor: use Spring Security's resource server #175 (resource server), feat: report output file logs #176 (output file logs), build: update the Kubernetes client #178 (Kubernetes client 28, SnakeYAML 2), ci: let Dependabot label all its pull requests #181 (Dependabot labels), fix: select only executor jobs for a single task #183 (executor job selector) and test: reach 100% test coverage #184 (100% coverage). The notes now have a ## Breaking changes section, as the 1.2.0 notes did: Java 21 (JAVA_OPTS), the upgrade order for filer labels, tokens only from the header, wildcards without path_prefix, the default page size and the new states.
• docs/upgrading.md: "To 1.3.0" merges the items of this PR and those added on dev. The upgrade order for filer labels (TESK API first, then the taskmaster of tesk-core 0.12.0 that labels filer jobs; Recreate if one deployment brings both) and Java 21 come first; the TES 1.1 fields item no longer says that ignore_error: true is refused; two small items of test: reach 100% test coverage #184 are added (a null groups claim gives no authorities instead of one named null; a task that can't be serialized fails with 500).
• docs/configuration.md: "Since 1.3.0" for TESK_API_AUTHORISATION_SERVICE_CLIENTS_*; docs/deployment.md: cosign example with 1.3.0.

The default taskmaster and filer images of TESK API stay at tesk-core 0.11.0: 0.12.0 isn't released yet, and a default that labels filer jobs would contradict the upgrade order during a rolling update. The TESK chart sets its own images.

Light lane: only version strings, the date and docs text (plus a merge of dev, whose code was reviewed in its own PRs), no logic, so no reviewer subagents; diff reviewed by hand.

Closes #156

Verification

• publish.py check docs/releases/1.3.0.md (the publish-release action at the commit 31f22fc that release.yml pins): passes.
• mkdocs build --strict: passes; the anchor #to-130 is unchanged.
• No test references the version; service-info.yaml, pom.xml and CITATION.cff say 1.3.0.
• Generated notes previewed against dev (releases/generate-notes, v1.2.0...dev): all 18 PRs, each listed in the curated notes.
• Code scanning: the CI image scan of the dev head 45e3a7f has no open critical or high alerts (44 medium, 10 low).
• CI on e2f6d79: all checks pass (CI passed: Lint, Test, Docs, Smoke test, Scan image; PR title, CodeQL, Sourcery with no new threads; the 4 Sourcery threads from 2026-11-12 stay resolved).

Open questions

• 1.3.0 or 2.0.0? Under SemVer, several changes break clients or deployments of 1.2.0: tokens in the URL (access_token) are ignored (refactor: use Spring Security's resource server #175), JVM options that Java 21 removed stop the JVM (build: move to Java 21 #161), wildcard outputs without path_prefix are refused (feat: refuse wildcards without path_prefix #152), GET /tasks pages by 256 (feat: default page_size to 256 as TES specifies #158), new states (feat: report the CANCELING and PREEMPTED states #151), and the upgrade order for filer labels (fix: select only executor jobs for a single task #183). 1.2.0 shipped comparable changes as a minor release with a Breaking changes section, so this PR keeps 1.3.0 and lists them the same way; the version is uniqueg's call. Choosing 2.0.0 means changing pom.xml, CITATION.cff, service-info.yaml, the notes' file name and the #to-130 anchors here first.
• There is no v1.3.0 milestone in this repo (only the closed v1.2.0), so test: reach 100% test coverage #179, fix: select only executor jobs for a single task #182 and the other issues weren't added to one; create it if the release should have one.

🤖 Generated with Claude Code

[sourcery-ai]

Reviewer's Guide

Configuration

Bump the project and built-in service-info versions to 1.3.0 and update the container verification example for the release.

• CITATION.cff L51-52
• docs/deployment.md L17
• pom.xml L8
• src/main/resources/service-info.yaml L15

Documentation

Add the curated 1.3.0 release notes and document upgrade impacts, new options, and their deployment requirements.

• docs/configuration.md L35
• docs/releases/1.3.0.md L1-45
• docs/upgrading.md L17-51, L79-102, L145-157 (+4 small edits)

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (45e3a7f) to head (e2f6d79).

Additional details and impacted files

@@            Coverage Diff            @@
##               dev      #155   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           51        51           
  Lines         2262      2262           
  Branches       254       254           
=========================================
  Hits          2262      2262           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sourcery-ai]

Hey - I've found 4 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="docs/upgrading.md" line_range="27-28" />
<code_context>
+  cancel request wait until the pods have ended; clients that know only the
+  states of TES 1.0 must accept the new ones.
+- **`backend_parameters`.** They are no longer stored or returned, also for
+  tasks created by earlier versions; with the view `FULL`, a task lists the
+  keys it ignored in `logs[0].system_logs`. Tasks that also set
+  `backend_parameters_strict: true` are refused with `400 Bad Request`, as
+  TESK supports no backend parameters.
</code_context>
<issue_to_address>
**Legacy ignored keys are unavailable**

When a caller views a task created before 1.3.0 that stored `backend_parameters`, for tasks created before 1.3.0, no ignored-key annotation exists, so the API cannot list historical backend-parameter keys in `system_logs`; callers relying on the note see no keys and cannot recover them from the API.

Clarify that the ignored keys appear in `system_logs` only for tasks created after the upgrade.
</issue_to_address>

### Comment 2
<location path="docs/upgrading.md" line_range="7" />
<code_context>
-From 1.2.0, clients may notice changed answers:
+From 1.2.0, deployments need no changes: the new options are off by
+default. TESK API 1.3.0 accepts the task fields and list filters of TES 1.1,
+and clients may notice changed answers:

 - **Wildcards without `path_prefix`.** An output whose `path` has wildcards
</code_context>
<issue_to_address>
**True ignore-error tasks are refused**

When clients upgrade with tasks that set `executors[].ignore_error` to `true`, clients submitting `executors[].ignore_error: true` encounter an unexpected `400 Bad Request` after upgrading because the upgrade notes say TES 1.1 task fields are accepted but omit this restriction.

Add the `ignore_error: true` rejection to the 1.3.0 upgrade notes.
</issue_to_address>

### Comment 3
<location path="docs/releases/1.3.0.md" line_range="11" />
<code_context>
+- Tasks report `CANCELING` while the pods of a cancelled task still run, and `PREEMPTED` when Kubernetes disrupted all failed executors (#144, #151)
+- `backend_parameters` are no longer stored or returned; ignored keys are logged and listed in `system_logs`, and service info lists `tesResources_backend_parameters` (`[]`) (#145, #147)
+- Outputs with wildcards but no `path_prefix` are refused with `400 Bad Request`, unless they go to `file:` URLs, as TES 1.1 requires (#148, #152)
+- Experimental: private executor images, with registry credentials in the executor fields `docker_registry`, `docker_login` and `docker_pass`, passed to Kubernetes as image-pull Secrets owned by the taskmaster's job and never returned (#55, #141)
+
+## Fixes
</code_context>
<issue_to_address>
**Registry address falsely implied hidden**

When a client relies on the release note to determine which private-image fields are returned, readers may conclude that none of the listed executor fields are returned, but `docker_registry` is stored with the task and returned by the API. This gives clients incorrect guidance about what information is exposed.

Clarify that only `docker_login` and `docker_pass` are not returned; `docker_registry` is returned.
</issue_to_address>

### Comment 4
<location path="docs/releases/1.3.0.md" line_range="10" />
<code_context>
+- `GET /tasks` filters by `state`, `tag_key` and `tag_value` (#143, #149)
+- Tasks report `CANCELING` while the pods of a cancelled task still run, and `PREEMPTED` when Kubernetes disrupted all failed executors (#144, #151)
+- `backend_parameters` are no longer stored or returned; ignored keys are logged and listed in `system_logs`, and service info lists `tesResources_backend_parameters` (`[]`) (#145, #147)
+- Outputs with wildcards but no `path_prefix` are refused with `400 Bad Request`, unless they go to `file:` URLs, as TES 1.1 requires (#148, #152)
+- Experimental: private executor images, with registry credentials in the executor fields `docker_registry`, `docker_login` and `docker_pass`, passed to Kubernetes as image-pull Secrets owned by the taskmaster's job and never returned (#55, #141)
+
</code_context>
<issue_to_address>
**Working file outputs appear rejected**

When a wildcard output omits `path_prefix` and its URL has no scheme, the release note says the request is refused, but TESK treats the schemeless URL as `file:` and accepts it, so clients are told to change requests that already work.

Clarify that schemeless URLs use `file:` behavior and are accepted without `path_prefix`.

Also at `docs/releases/1.3.0.md:11`.
</issue_to_address>

Sourcery assessment

Approval pending. 4 findings to address first.

Blocking findings: docs/upgrading.md:28, docs/upgrading.md:7, docs/releases/1.3.0.md:11, docs/releases/1.3.0.md:10

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[sourcery-ai]

Sourcery assessment

Approved.

[sourcery-ai]

Linked issues

Checked at commit e2f6d79

#156 build: prepare the 1.3.0 release · 4 of 4 met

#	Requirement	Status	Notes
1	Set the 1.3.0 version in pom.xml, CITATION.cff with date-released, and the built-in service-info.yaml.	✅ Met	All three files identify the release as 1.3.0; CITATION.cff also includes date-released.
2	Add curated release notes in the organisation's format.	✅ Met	docs/releases/1.3.0.md follows the release-note sections used for 1.2.0.
3	Change the upgrading section to “To 1.3.0” and cover the listed client-noticeable changes.	✅ Met	The section covers wildcards without path_prefix, CANCELING/PREEMPTED, backend_parameters, refused TES 1.1 values, and service-info type.version.
4	Mark the new settings “Since 1.3.0.”	✅ Met	The TESK_API_AUTHORISATION_SERVICE_CLIENTS_* configuration entry ends with “Since 1.3.0.”