The platform always sets CA_TRUST_NAME together with CA_TRUST_CERT, so the infinito-dev-ca default was dead code that could hide a missing setting. The entrypoint now fails with a clear message instead.
Both provisioners follow nextCursor for workflows and step skip for API
keys until a short page arrives. A cursor n8n repeats, or a key listing
that ignores skip, would keep that loop running forever and hang the
deploy instead of failing it.
workflows_named now remembers every cursor it followed and exits with
"FAILED listing workflows: nextCursor repeats" when one comes back.
api_keys_labelled exits when a non-empty page brings no key id it has not
already seen. Normal paging is unchanged.
Four regression tests drive both scripts against a fake API that repeats
its cursor or ignores skip; without the guards exactly those four fail.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every make quality run rewrites the three http_regex patterns in
meta/services.yml from single to double quotes and leaves the tree dirty.
Both forms load to the same strings; committing the autoformat output ends
the drift.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Matomo 5.14.0 renders the "What's new" entry of its top bar, once for the
desktop menu and once for the mobile one, as <a onclick=... href="javascript:">
(plugins/CoreAdminHome/Menu.php). Without the logout service, script-src-attr
carries only 'self' 'unsafe-eval', so the browser blocks both handlers.
Playwright 1.64 (Chromium 156, f1dbd2d92f) now reports those blocks on the
console, and the administrator login spec of variant 1 fails on them. That
broke the three compose workspace jobs of main run 37856203791. The same
variant passed on Playwright 1.63 with an identical header.
script-src-attr now carries 'unsafe-inline', which every logout-enabled
deploy already serves through the logout injector. The CSP filter
deduplicates the token there, and script-src keeps the 'unsafe-inline' it
already unions in from script-src-elem.
Verified on a local variant 1 stack. The Playwright trace shows exactly
those two onclick anchors. With the header patched live, the spec passes;
with the original header restored, it fails again with the same two
violations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
cAdvisor bound a hardcoded /var/lib/docker/. When the daemon keeps its
data root elsewhere, swarm rejects the task because the bind source does
not exist ("invalid mount config for type bind: bind source path does not
exist: /var/lib/docker/") and the stack never converges. In main run
37856203791 all 18 swarm jobs that deploy Prometheus failed this way after
scripts/tests/deploy/utils/filesystem/docker_dataroot.sh moved every node's
data root to /mnt/docker-fs/docker, on ext4, btrfs and zfs alike.
The role now reads DockerRootDir from the daemon on STACK_HOST and binds
that path as source and target. cAdvisor v0.55.1 takes its storage dir from
docker info, so the target has to follow the daemon's root instead of
staying at /var/lib/docker. The probe needs the container CLI and a running
daemon, which a single-role compose deploy only gets later from
sys-svc-container inside sys-stk-backend, so the role loads it first under
the usual run-once guard.
Verified with a local compose deploy of variant 2: the rendered compose file
carries /var/lib/docker:/var/lib/docker:ro from the probe and cAdvisor runs
healthy.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
#832 probes /healthz/ready on every consumer and proxies it to the app root,
where Bridgy Fed, Hermes and the XMPP web listener answer 404 by design, so
their probe_success stayed 0. A consumer can now name the path in
services.prometheus.ready_path; the accepted status codes stay unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
`make quality-high` rewrote these files on every branch: the SuiteCRM
README and the root role table lacked the Redis service #881 added, the
session path test was not formatted, and an OpenTalk secret description
from #873 was not wrapped.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
n8n 2 returns ten API keys and a hundred workflows per page by default. A
stale managed key behind the first page survived, and a managed workflow
behind it was created a second time. Both scripts now follow every page,
narrowed by label or name, and keep the exact match in the script.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The Redis service #881 added is always on and only holds sessions, so no
spec can gate on it. tests/integration/roles/playwright/test_env_services_match.py
failed on main and in every pull request because the service carried
neither a REDIS_SERVICE_ENABLED flag nor the marker the other Redis
consumers use.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
n8n 2 pages GET /rest/api-keys as {data: {items, counts, totals, owners}},
ten keys at a time, and matches `label` as a substring, so walking the body
raised "'str' object has no attribute 'get'". It also enforces API key
scopes, so activating the MCP server workflow needs `workflow:activate`.
Both scripts now read every list and create response through one
normalisation that unwraps the page, look the managed key up by label, and
name an unexpected shape by its keys only. The normalisation is taken over
from a392e2dd49 on feature/store-i18n.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The unauthenticated half of the relay probe passed on any 5xx answer.
A server that refused the recipient for another reason would have
counted as "relay denied". It now requires 550, the code Stalwart gives
for a denied relay.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With three swarm replicas the PHP session files on the shared NFS volume
were read as empty under concurrent requests of one browser, so SuiteCRM
answered 403 on /api/graphql and dropped the session. Sessions now live in
Redis with session locking that waits like flock did; the phpredis version
is pinned in services.yml with its own update source, and the engine lookup
renders the save path.
Refs #879
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Buildx 0.38.0 gates host networking in bake behind an entitlement that
Compose never grants, so `make compose-up` failed wherever Compose had to
build the image itself. The build block asked for it without need:
scripts/image/build.sh builds the same Dockerfile on the bridge network.
Closes#875
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The web frontend, the controller and the recorder were pinned to v2.9.0,
v0.34.1 and v0.16.2, a mix of the 26.2 and the 26.1 line, and excluded
from the image updater with nocheck: docker-version. Nothing moved them.
They now sit on the set OpenTalk publishes as product version 26.2.1 in
ot-setup (v2.9.2, v0.34.5, v0.17.5), and each pin names that bundle as its
version source, so the three move together with the next product version.
The markers are gone.
Recorder v0.17 no longer reads recording jobs from RabbitMQ or logs in
with an OIDC service account. The controller starts recordings on the
recorder's REST API and both sides authenticate with API keys:
recorder.toml.j2 names the controller and the recorder's own key,
controller.toml.j2 enables roomserver.modules.recording, the secret
recorder_api_secret replaces recorder_oidc_client_secret and the Keycloak
client opentalk-recorder is no longer created.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The README said a templated pin moves whenever the assembled value
changes. newer_version() additionally rejects an assembled value that
sorts below the current pin, which
test_an_unchanged_or_older_templated_tag_reports_nothing covers.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
