especially with the new Selenium driver, sending the click() event may
not wait synchronously until all event handlers on the element clicked
have fired and run to completion. This way, the "updating" DOM attribute
used to synchronize in this case may not have been touched. Now we wait
for the checkbox to really be ticked before continuing. Then we can be
sure that the "updating" flag has also been set.
Assisted-By: Opus 4.8
Two related fixes for the permanent hang where a request thread held the
raceTrackersByRegatta write lock while parked in Object.wait(), timing out all
subsequent requests to the service.
TrackedRaceImpl.waitForAllRaceLogsAttached(): the wait guard re-evaluates the
live attached-race-log count inside the synchronized(latchForRaceLogs) block
instead of a stale local captured before entering the monitor. The stale local
could never change, so a notifyAll() that fired between the initial read and
entering wait() was lost, parking the thread forever (classic lost-wakeup).
RacingEventServiceImpl.addRace(...): split the register-or-notify handshake so
that only *claiming* (removing) the callbacks for the new tracker happens under
the raceTrackersByRegatta write lock, atomically with publishing the tracker;
the callbacks are then *invoked* after the lock is released. A callback may
block during tracker startup (waiting for race logs to attach), and previously
that wait ran while holding the global write lock, turning a single stalled
tracker into a service-wide outage. The read-locked find-or-enqueue in
getRaceTrackerByRegattaAndRaceIdentifier(...) still races atomically against the
claim, so no callback can be lost.
Assisted-By: Claude Opus 4.8
The Media tab replaces the event activity asynchronously, so wait for the new tab content before constructing its page object.
Assisted-By: GPT-5.6-sol
Wait for lazily loaded tab content instead of failing on transient absence, and sequence and track event, regatta, and leaderboard creation callbacks so dependent dialogs see persisted state.
Assisted-By: GPT-5.6-sol
Extract a reusable interactability wait so media URL entry waits for the animated dialog to settle before clearing the input. Track public-server configuration requests and explicitly handle the expected tenant warning during the affected login test.
Assisted-By: GPT-5.6-sol
this is intended to help with animated elements such as the race map
settings, or an animated error dialog's buttons.
Assisted-By: Claude Code + GPT 5.6 Sol
Now that the Selenium suite is on 4.13.0 (#6298) and speaks the W3C WebDriver
protocol, the Firefox 140 pin is no longer needed: the pin was a symptom of
Selenium 3's JSON Wire Protocol drifting from modern geckodriver/Firefox.
Default the firefox_version workflow_dispatch input to "latest" (both the input
default and the empty-input fallback) so CI tracks the current Firefox; the
setup-firefox action pairs a matching geckodriver automatically. The input is
kept so a specific version can still be pinned at dispatch time if a future
Firefox release regresses.
Assisted-By: Claude (claude-4.8-opus)
Selenium 4's selenium-os module (org.openqa.selenium.os.CommandLine, used by
DriverService.start() to launch the driver binary) depends on Apache Commons
Exec 1.3. Selenium 3's fat client-combined jar bundled it; the modular
Selenium 4 needs it as a separate transitive. Its absence caused a runtime
NoClassDefFoundError: org/apache/commons/exec/ExecuteWatchdog on the first
driver session start. Added commons-exec-1.3.jar (the version pinned by
selenium-os 4.13.0) to lib/ and wired it into Bundle-ClassPath, build.properties
and .classpath. Not re-exported, as only selenium-os references it internally.
Assisted-By: Claude (claude-4.8-opus)
The Selenium 4 wrapper rewrite dropped the com.google.common.base and
com.google.common.collect exports that the Selenium 3 bundle provided. The
test bundle uses Guava directly (Objects, Function, ImmutableList) via
Require-Bundle, so Tycho's PDE compiler rejected those references with
"Access restriction: ... is not API". Plain javac did not catch this because
it ignores OSGi Export-Package/Require-Bundle API boundaries. Re-exporting the
two packages restores API access, matching the Selenium 3 behavior.
Assisted-By: Claude (claude-4.8-opus)
Selenium 3.x only speaks the legacy JSON Wire Protocol, which forces us to
pin old browser versions. Selenium 4 brings the W3C WebDriver protocol.
Since the reactor still runs on Java 8 and Selenium 4.14+ requires Java 11,
4.13.0 is the migration target: the last Java-8-compatible release.
org.openqa.selenium.osgi wrapper bundle:
- Drop the Selenium-3 client-combined fat jar and its transitives.
- Add the 12 Selenium 4.13.0 modules + selenium-chromium-driver and the
required transitive runtime deps (Netty async HTTP client, OpenTelemetry).
- Keep the legacy org.json jar (still consumed by the test bundle and
previously re-exported here); DevTools/CDP jars intentionally omitted
(the suite uses no CDP).
- Re-scope Export-Package to the 4.13.0 package layout; keep
Bundle-RequiredExecutionEnvironment JavaSE-1.8. Bump bundle to 4.13.0
and mirror the jar list in .classpath, build.properties and pom.xml.
com.sap.sailing.selenium.test source fixes:
- WebDriverWait(WebDriver, long) -> WebDriverWait(WebDriver, java.time.Duration).
- org.openqa.selenium.internal.WrapsElement -> org.openqa.selenium.WrapsElement.
- ElementNotSelectableException (removed) -> ElementNotInteractableException.
- Bump wrapper-bundle dependency to 4.13.0.
The full test bundle compiles cleanly against the new wrapper on Java 8.
Assisted-By: Claude (claude-4.8-opus)
Prepare consumers for the release producer switching from an explicit
application/x-tar content type to the extension-inferred application/gzip.
All sites that locate the release tarball by asset content_type now accept
the set application/x-tar, application/gzip, application/x-gzip and
application/x-compressed-tar (the types commonly seen in the wild for a
gzip-compressed tar), instead of matching application/x-tar exactly.
This is behavior-preserving for existing application/x-tar releases and
forward-compatible with application/gzip releases, enabling a later,
risk-free switch of the release workflow to action-gh-release's files: input.
Consumers updated:
- GithubReleasesRepository.java (Set membership instead of String.equals)
- refreshInstance.sh (both jq selectors)
- github-download-release-assets.sh (both jq selectors)
Assisted-By: Claude (claude-4.8-opus)
Folding the tar.gz upload into softprops/action-gh-release's files: input
(commit f6143d18) broke production installs: that action derives the asset
content type via the mime-types library, which maps .tar.gz to
application/gzip. Production installers (refreshInstance.sh,
github-download-release-assets.sh) select the tarball with
select(.content_type=="application/x-tar"), so nothing matched and installs
could not find the release.
Revert to the two explicit actions/upload-release-asset@v1 steps that set
asset_content_type: application/x-tar and text/plain, and add a comment
warning against folding them back in.
Assisted-By: Claude (claude-4.8-opus)
The workflow-telemetry action renders CPU/memory charts as mermaid
xychart blocks with every sample inlined as text (see src/graphing.ts);
there is no downsampling. GitHub renders mermaid with a fixed
maxTextSize of 50000 chars that the diagram author cannot raise, so on
our ~3h+ builds the default 5s sampling (~2300+ samples) blew past the
limit and the charts failed to render ("Maximum text size in diagram
exceeded").
Sampling every 30s yields ~390 points over a 3h15m run (~10k chars of
mermaid source), well under the limit with headroom for longer runs,
while keeping enough resolution to read CPU/memory trends.
Assisted-By: Claude (claude-4.8-opus)
Fold the tar.gz and release-notes.txt uploads into the single
softprops/action-gh-release step using its files: input, and drop the
two actions/upload-release-asset@v1 steps. Those steps still emitted the
deprecated ::set-output workflow command; action-gh-release infers each
asset's content type from its file extension.
Assisted-By: Claude (claude-4.8-opus)
On workflow_dispatch there is no 'before' field in the event payload, so
dorny/paths-filter cannot compute a meaningful diff and warns, falling back
to a last-commit-only diff. A manual dispatch is an explicit request to build,
so skip the filter step on that event and force the 'changes' job's should_run
output to true. push/PR events are unchanged and still gated by the filter's
'code' output. This also keeps the changes job in agreement with the build
job's if-condition, which already forces the build on workflow_dispatch.
Assisted-By: Claude Opus 4.8
The upstream catchpoint/workflow-telemetry-action v2.0.0 (its latest
release) still declares the node20 runtime in action.yml, so GitHub
force-runs it on Node 24 and emits a deprecation warning. There is no
upstream release that resolves this.
Switch to ycfreeman/workflow-telemetry-action@v3.0.2, a maintained fork
upgraded to node24 whose inputs are a superset of upstream (comment_on_pr
is unchanged). Pinned to the specific commit SHA to avoid mutable-tag
risk, with the version noted in a comment.
Assisted-By: Claude (claude-4.8-opus)
they are now compliant with Node 24, the basis for Github Actions
runners. workflow-telemetry-action still requests Node 20. We'll see if
there is still a maintainer around who may be willing to upgrade this to
Node 24.
A cancelled build is indeterminate — the tests might have passed had the
run not been interrupted — so posting build-gate=failure would be
misleading. Restrict the failure post to build.result==failure (a real
tested failure); a cancelled trusted build now posts NOTHING, leaving the
build-gate context absent so the PR stays blocked at "Expected" with no
red X. Re-run to obtain a real verdict.
Assisted-By: Claude Opus 4.8
The previous build-gate was a JOB, and GitHub Actions auto-creates a
check-run for every job whose conclusion is filled from the job's fate —
including "skipped" when the job's if: is false. Branch protection /
rulesets treat a skipped required check as SATISFIED (mergeable), so a
compile-only fork PR reported build-gate=skipped=passed and became
mergeable without tests (PRs #53/#54; #53 merged this way). No job can
represent "absent": a skipped job still materializes a skipped check-run.
The earlier attempt to make it exit 1 (red) worked but was ugly and, on a
failed build, still mis-reported skipped in practice.
A commit status (legacy Statuses API) is created only if we explicitly
POST it, and a skipped STEP posts nothing (steps are not check-runs). The
ruleset matches the required context "build-gate" by NAME across both the
Checks and Statuses APIs, so a posted commit status with context=build-gate
satisfies it exactly as the old check-run did — the ruleset needs no change.
Change: remove the build-gate job; add job post-build-gate-status (named so
its own auto check-run carries a context the ruleset ignores) whose single
step POSTs a commit status context=build-gate:
- state=success when the change was trivial (build skipped, no relevant
changes) OR a full build ran WITH tests and succeeded;
- state=failure when a full build ran WITH tests and failed/cancelled
(loud red X for a committer's own broken build);
- NOTHING for any compile-only run (fork PR, *-reviewed-for-compile,
workflow_dispatch skip_tests), succeeded or failed — so the build-gate
context stays absent and the PR is blocked at "Expected" with no red X.
The status is posted against the PR HEAD sha on pull_request events
(github.sha there is the ephemeral refs/pull/N/merge commit the ruleset
does not evaluate) and github.sha otherwise. Merge qualification for fork
code still comes only from a maintainer pushing a *-reviewed-for-build tag
(full trusted build with tests), which posts the success status.
compile-gate (advisory) is unchanged.
Assisted-By: Claude Opus 4.8
A required status check whose job is skipped by its own if: still
materializes a check run with conclusion "skipped", which GitHub branch
protection / rulesets treat as SATISFIED (mergeable). The prior design
assumed an if:-false job would leave the required check "pending" and
block merge without a red X; that pending state does not exist for a job
that is part of a triggered workflow. As a result, a successful
compile-only fork pull_request build reported build-gate as "skipped"
= passed, and PRs #53/#54 became mergeable WITHOUT the secret-bearing
test build ever running (#53 was merged this way).
Fix: build-gate now runs unconditionally (if: always()) and, for a
successful compile-only run (build success AND skip_tests==true), exits 1
instead of skipping, so the required check goes red and the PR stays
un-mergeable. Only a genuine full build with tests, or a legitimate
trivial-change skip, satisfies the gate. Merge qualification for fork
code still comes solely from a maintainer pushing a *-reviewed-for-build
tag. compile-gate (advisory) is unchanged and still shows the compile
succeeded.
Assisted-By: Claude Opus 4.8
Previously the option-name branch was guarded by `$cur == -*`, so a Tab
in option position with an empty current word produced nothing. Drop the
guard: compgen -W filters by $cur anyway, so an empty cur now lists every
option while a partial still narrows. Value completion is unaffected —
those cases return earlier in the function.
Assisted-By: Claude Opus 4.8
Tab-completes the script's named options and, intelligently, their
values against the git repo containing the CWD:
- remote-name options complete against 'git remote';
- remote-branch options (--upstream/downstream/fork-branch) complete
against the branches OF THE RESOLVED REMOTE, resolving each role to
a remote with the same precedence the script uses (explicit
--*-remote on the line > MERGE_U2D_* env var > built-in default);
- --local-*-branch options complete against local branches.
Install by sourcing from ~/.bashrc or symlinking into a
bash-completion completions dir under the command's basename.
Assisted-By: Claude Opus 4.8
Add MERGE_U2D_* environment variables that seed the default for every
command-line option, with precedence CLI option > env var > built-in
default. This lets the script run with no arguments when e.g.
MERGE_U2D_FORK_REMOTE is exported from .bashrc; -h shows the live
resolved defaults.
Also fix the step-7 fallback so that when 'gh pr create' refuses because
an open PR already exists for the fork head (the older-head path, where
the push already updated it in place), the existing PR is found and its
URL reported instead of erroring. 'gh pr list --head' filters by branch
name only, so match on the bare fork branch plus a headRepositoryOwner
filter, mirroring the early idempotency check.
Assisted-By: Claude Opus 4.8
A regression: replacing 'if: always()' with the bare content guard
'if: ${{ !(needs.build.result == '\''success'\'' && ... skip_tests == '\''true'\'') }}'
lost always() semantics. Because 'build' is in needs:, a FAILED build then
cascade-skips build-gate (GitHub's default: a dependent job is skipped when a
needs: dependency fails unless the if: contains always()/!cancelled()). That
left the REQUIRED build-gate check quietly pending on a real build failure
instead of going red (observed on run 33162860634, a push to main with a
failing build).
Restore always() so the gate runs for every build outcome and the narrow guard
alone decides the sole non-run case (a *successful* compile-only build, which
must stay pending/blocked, not red). A real build failure now runs the gate and
it exits 1 -> red. Documented why always() is required in the comment.
Assisted-By: Claude Opus 4.8
A successful compile-only run (fork pull_request, *-reviewed-for-compile tag,
or workflow_dispatch with skip_tests=true) previously made build-gate exit 1:
the required check went red AND the whole Actions run showed as failed, even
though compilation succeeded. That reads as breakage when nothing broke.
Fork pull_request runs get a read-only GITHUB_TOKEN (permissions: is capped to
read-only regardless of what the workflow requests), so the Commit Statuses and
Checks APIs both 403 there — a posted 'neutral'/status cannot mark the check.
And neutral would not block merge anyway (GitHub treats neutral/skipped/success
as passing for required checks). The only state that is both non-red and still
merge-blocking is a required check that is never reported: it sits 'Expected —
waiting' (pending).
So build-gate is now SKIPPED via a job-level if: for exactly the successful
compile-only case. A required check whose job never starts stays pending, so the
PR remains un-mergeable without a red X and the run is not marked failed. This
must be a job-level skip (job never starts): a job that runs and reports
conclusion 'skipped' counts as PASSED and would let the PR merge.
The guard is deliberately narrow — !(build.result == success && skip_tests ==
true) — so a compile-only build that FAILED still runs the gate and goes red,
and the trivial-change skip still runs and goes green (docs-only PRs are not
left pending forever). The now-unreachable compile-only branch in the gate body
is removed. Merge qualification for fork code continues to come from a
maintainer pushing a *-reviewed-for-build tag (full trusted build with tests).
compile-gate (advisory) still runs and goes green, giving a clear positive
compile signal beside the pending build-gate.
Assisted-By: Claude Opus 4.8
actions/checkout@v4, setup-java@v4 and upload-artifact@v4 run on the node20
runtime, which is EOL (Node 20 reached end-of-life on 2026-03-24) and emits a
deprecation warning on every run. Bump each to its current release, all of
which run on node24, and pin by full commit SHA (matching how the third-party
actions in this workflow are pinned):
- actions/checkout v4 -> v7.0.1 (3d3c42e5aac5ba805825da76410c181273ba90b1)
- actions/setup-java v4 -> v6.0.0 (dd06d9cba3e5552c54d9f8ea23572deb30010f7c)
- actions/upload-artifact v4 -> v7.0.1 (043fb46d1a93c77aae656e7c1c64a875d1fc6a0a)
checkout v5+ requires Actions Runner >= v2.327.1, which GitHub-hosted
ubuntu-latest satisfies. setup-java v6 is unaffected for the Temurin 8/17/25
toolchains used here. actions/upload-release-asset@v1 is intentionally left as
is: it is archived with no maintained successor and belongs to a separate
change, not this node20 sweep.
Assisted-By: Claude Opus 4.8
A submitted PR now triggers a build automatically, split by trust:
- Same-repo PR (branch pushed by a committer): full build with tests and
secrets — same trust level as a direct branch push, which already builds
with secrets. build-gate can go green with no manual tag.
- Fork PR: compile-only with NO secrets. GitHub withholds secrets from fork
pull_request runs at the event level, and a compile-only build needs none,
so this is both automatic and safe. build-gate stays red; the secret-bearing
full build of fork code remains gated behind a maintainer pushing a
*-reviewed-for-build tag.
Uses pull_request (not pull_request_target), so fork runs get a read-only
token and no secrets; with the secret env values already resolving to '' when
tests are skipped, fork code never meets a secret.
- pull_request trigger: types [opened, synchronize, reopened, ready_for_review]
with the same paths-ignore as push; no branches: filter (targets PRs into any
base branch).
- build job if:: draft PRs are excluded (build only once marked ready).
- Determine build mode: a fork pull_request (head.repo.full_name != the base
repo) sets skip_tests=true; same-repo PRs run the full build.
The conditional secret env, -t flag, Test Reports guard, and both gate jobs
already key on the computed skip_tests flag, so they need no change.
Assisted-By: Claude Opus 4.8
A maintainer reviews a fork PR's exact SHA, then pushes a tag at that SHA:
'*-reviewed-for-compile' runs a compile-only build with NO secrets (cheap
sanity check), '*-reviewed-for-build' runs the full build with tests and
secrets. A tag push is a trusted push event in the base repo, so it receives
secrets — the only way to run secret-bearing validation on fork-authored code.
- push trigger: keep branches: ['**'] (required so the new tags: filter does
not silently disable branch triggers) and add the two reviewed-tag families.
- build job: a 'Determine build mode' step computes skip_tests (true for a
-for-compile tag or a workflow_dispatch skip_tests=true) and exposes it as a
job output. The five test-runtime secrets resolve to '' when skip_tests is
true, so their values never enter the environment on a compile-only run; -t
is passed on the same flag. Test Reports step is skipped when tests are.
- build-gate (required check): green only for a genuine full build with tests,
or a trivial-change skip; a compile-only success fails it. This also fixes a
pre-existing bug where a skip_tests=true dispatch satisfied the gate.
- compile-gate (new, advisory): green whenever the build compiled, regardless
of tests, giving -for-compile runs a distinct check without touching the
required build-gate.
Assisted-By: Claude Opus 4.8
Upstream committers have more freedom handling PRs, so the pull_request_review
trigger, the privileged-pr-build environment gate, and the associated
head-SHA / persist-credentials / base-ref conditionals are not needed here.
Remove them, keeping the plain push/workflow_dispatch build.
The dorny/paths-filter correctness fix (v4.0.3 + some-with-excludes + a
positive '**' rule) is retained: it fixes a pre-existing bug where docs-only
changes were misclassified as code changes on the push path too.
The downstream (SAP) branch keeps the environment-based approval approach via
a subsequent 'merge -s ours'.
Assisted-By: Claude Opus 4.8
v4 adds the 'some-with-excludes' predicate-quantifier, which is the natural
fit here: code is true only when a changed file matches the positive '**'
rule and none of the '!' exclusions. Replaces the v3.0.3 'every' workaround.
The only v4 breaking change is the Node 20->24 runtime bump.
Assisted-By: Claude Opus 4.8
The 'code' filter used only negated rules under the default 'some'
quantifier. picomatch treats '!README.md' as "any path except README.md",
so a changed README.md still matched a rule and set code=true, forcing a
full build for docs-only PRs (as seen on PR #48).
Add a positive '**' rule and set predicate-quantifier: 'every' (the pinned
v3.0.3 does not support the v4-only 'some-with-excludes'), so code is true
only when a changed file matches the '**' rule AND all '!' exclusions,
i.e. it is a non-trivial file.
Assisted-By: Claude Opus 4.8
The changes job used dorny/paths-filter without an explicit base/ref, so on
a pull_request_review event (which, unlike pull_request, is not auto-detected
by the action) it diffed against the default branch with a shallow clone and
treated every file as changed. A docs-only PR therefore ran a full build and
hit the deployment-review gate needlessly.
Diff the PR head (github.event.pull_request.head.sha) against the PR base
(github.event.pull_request.base.sha) explicitly, fetch full history so the
merge-base resolves, and grant pull-requests: read. Push and workflow_dispatch
behavior is unchanged (base/ref fall back to empty, fetch-depth to 1).
Assisted-By: Claude Opus 4.8
Add a pull_request_review (submitted) trigger and gate the changes/build
jobs on an approving review, so a PR (possibly from an untrusted fork)
never builds with secrets before a maintainer has vetted the exact code.
Secrets are released via a conditional 'privileged-pr-build' environment
referenced only on review runs; on push/workflow_dispatch the environment
name is empty (no gate), keeping existing behavior unchanged. The
environment holds no secrets, so repository-level values are used via
environment>repository precedence and rotation stays in one place.
Review runs check out the PR head SHA with persist-credentials: false so
untrusted build code cannot scrape the token. build-gate now treats a
skipped changes job (non-approving review) as pass rather than failure.
Assisted-By: Claude Opus 4.8
The local / master-SNAPSHOT / master-latest / 19/08/2026 09:58 update on
their yb.tl site may have broken things for us. E-mail to their support
address has been sent, and we need to wait until we receive
clarification.
In POLYCHROMATIC mode, Colorline.setPath(...) built zero polylines for a
single-vertex path, so getLength() returned 0 instead of 1. This broke the
FixesAndTails invariant tail.getLength() == lastShownFix - firstShownFix + 1,
after which mergeFixes computed out-of-range tail indices and threw an
IndexOutOfBoundsException while scrubbing the time slider.
Represent a one-vertex path as a single Polyline holding that vertex, matching
the interim single-vertex state insertAt builds up and getLength's case 1
already expects.
Assisted-By: Claude (claude-4.8-opus)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Axel Uhl
