Both were updating `github-actions` daily, so both proposed the same bumps.
actions/setup-python v7 arrived twice within an hour: Renovate as #5575, Dependabot
as #5576.
Renovate is the one to keep. It pins actions to digests via
`helpers:pinGitHubActionDigests`, so master carries
`actions/setup-python@5fda3b9... # v7`, while Dependabot proposes a bare `@v7` and
would undo that pinning. Renovate's bumps also merge on a branch once CI has run
them, whereas Dependabot's sit outside every automerge rule here and need a human
for each one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Its `paths` filter listed `i18n/**` but not the workflow file, so a change to the
workflow - an action bump, say - triggered nothing. Those bumps automerge on a
branch, so they were merging with nothing having run them.
The Molecule workflow already lists itself for this reason. `update-translations.yml`
cannot do the same: it only runs on pushes to master, and it holds `contents: write`
and `pull-requests: write` to open translation PRs, so running it from a dependency
branch would be worse than not exercising it. Its bumps stay unexercised on purpose,
and a broken one shows up as a failed translations run rather than as anything users
see.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
It read "The API key is intentionally not required. Some OpenAI-compatible APIs
do not require a key", while validate_config.yml fails when the key is empty and
the provider is enabled. Enabling the provider against a keyless endpoint stopped
with "You need to define a required configuration setting".
baibot is the authority here, and it agrees with the validation rather than the
comment: `openai::Config` takes `api_key: String`, whereas the provider whose key
really is optional is a different one, `openai_compat`, with
`api_key: Option<String>`. So the comment described a real baibot feature, just
not this provider's.
The validation stays as it is; the comment now says what the code does, and
points at the provider the keyless case belongs to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
The image tag prefixed `ig-` when `..._meta_mode` was `instagram`, but this role
does not accept that mode any more: `..._database_suffix` and
`..._bridge_username_prefix` map only `facebook`, `facebook-tor` and `messenger`,
so `instagram` raises an undefined-key error long before the tag is rendered.
Instagram has been a separate bridge since v26.07 and is handled by
matrix-bridge-mautrix-meta-instagram, which hardcodes the prefix. Left over from
before that split.
The comment stays, reworded: both bridges still share a container image
repository, so an `ig-` prefix on a tag here would mean this role had pulled the
other bridge's image - which is what the Molecule scenario asserts against.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Eight scenarios in, the same few things keep deciding whether a scenario is
worth having, and none of them were obvious beforehand:
- Falsify every assertion, not just enough to see red. One control asserted that
a component emitted no DEBUG records from a module and passed just as happily
with that module set to `debug`, because it emits none on a first run either
way. Green for the wrong reason, and only breaking it deliberately showed that.
- `ActiveState == active` with `NRestarts == 0` can both hold while a component
is completely broken, when it catches its errors and retries rather than
exiting. Two of the eight behave that way.
- Startup lines are the oldest in the journal, so tailing loses them. Grep, and
strip ANSI first.
- Parse rendered configuration and assert on structure, so a value under the
wrong key cannot pass.
- `molecule converge` on a running instance does not restart the container, so a
falsification can pass for that reason alone.
Also documents that a role's scenario obliges it to join the automerge list, and
that prek enforces the two staying in step.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
The annotation read `depName=depName=ghcr.io/...`, so Renovate looked up a
package literally named `depName=ghcr.io/the-draupnir-project/draupnir` and found
nothing. Both Draupnir roles have been invisible to Renovate since v3.0.0 landed
in April, and the dependency dashboard has been reporting it as a repository
problem the whole time:
Failed to look up docker package
depName=ghcr.io/the-draupnir-project/draupnir: no-result
Checked every other annotation under roles/custom/ for the same shape; these two
were the only ones.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
A component bump touches that role's defaults/main.yml, which is on the Molecule
workflow's path filter, so the change-detection job runs that role's scenario.
The bump therefore only merges once the new version has actually been started on
the configuration the role renders. That is a real gate, and a stronger one than
a human reading a version number in a diff.
Patch only. A minor carries behaviour changes that no static rule can judge - the
MASH fleet tried a minor-automerge preset across 21 stateless roles and reverted
all of them, because reading a given release's notes is what decides it, and that
is a job for a human or an agent rather than a config file.
Branch push rather than a PR, as with the other automerge rules here.
The list has to stay in step with the roles that actually have a scenario, so
bin/check-molecule-automerge-list.py enforces it from prek. The direction that
matters is a role keeping automerge after losing its scenario: bumps would then
merge with nothing exercising them. It reports the harmless direction too, since
a role gaining a scenario without being listed is usually an oversight.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Anything under molecule-shared/ - the helper container images, Postgres, and the
Python pins - is on the Molecule workflow's path filter, and a change to a shared
file makes the detect job run every scenario rather than a subset. So an update
there is already gated on the whole suite passing on its own branch, which is a
stronger check than a human reading the diff.
Branch push rather than a PR, matching how the housekeeping updates in this file
already work: nothing to review and no email on success, and a failure still
surfaces as a PR.
This is also how a new Postgres major reaches us. The bump to the pin runs every
scenario against it before it can merge, so if a component does not cope with the
new major we find out from a failed Renovate branch rather than from a user.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
The scenarios worked around Postgres 18's data layout change by mounting the
tmpfs at /var/lib/postgresql. The postgres role solved the same problem
differently and better, when it bit us there: it sets PGDATA explicitly, and to
/data rather than anywhere beneath /var/lib/postgresql, because that path is a
VOLUME in the official image and nothing can be mounted under it.
Doing the same here means the scenarios exercise the layout the role actually
deploys, and that a future image changing its own default cannot move the data
directory out from under them.
Ref: https://github.com/docker-library/postgres/pull/1259
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
`group_vars/matrix_servers` selects postgres whenever postgres is enabled, which
is the default, so postgres is what essentially every deployment runs. The
scenarios were testing sqlite - a path almost nobody is on.
How little that path is used is not a guess: the mautrix-meta bridges could not
start at all under sqlite, and nobody reported it. Testing the engine users are
actually on is worth more than keeping coverage of the one they are not, so no
scenario is left behind on sqlite.
Four of the eight scenarios have a database and are converted; the other four
have none and are untouched.
molecule-shared/tasks/postgres.yml stands Postgres up on the scenario's network,
with the data directory on a tmpfs since it is thrown away with the container.
The image is pinned at the major the postgres role deploys to new installations
and left to Renovate: when a new major lands, the PR bumping that pin runs every
scenario against it, which is the earliest warning we get that a component does
not cope.
Each scenario gives its database and user names that differ from the role's
defaults, so the component reaching the database proves the role built its
connection string out of them. The assertions moved from "a file appeared at the
path we configured" to "these tables exist", which is strictly stronger: tables
can only appear once the component has resolved the hostname, authenticated with
the credentials the role rendered, and run its migrations to completion.
Costs about 10 seconds per affected scenario (115s to 125s locally for
mautrix-whatsapp), on jobs that run in parallel.
Gotcha worth recording: since Postgres 18 the image puts PGDATA in a versioned
subdirectory and refuses to start if it finds a mount at the old
/var/lib/postgresql/data, so the tmpfs is mounted at /var/lib/postgresql.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
They were hard-wrapped at 80 characters, broke mid-parenthesis, and spent lines
restating what the code below them does.
Rewrapped at natural boundaries instead, with the narration dropped and only the
reasons, gotchas and surprises kept. Section dividers stay - they delineate long
plays rather than narrate them.
Comments only; no scenario behaviour changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
`just molecule` leaves a shared virtualenv of over 500 MB under var/, plus a
~7 MB Ansible home per role that has a scenario. Neither is reclaimed by
anything today.
`--idle-days N` limits it to what has not been touched recently, so it can be
run unattended without taking the cache out from under a scenario being worked
on right now.
The two directories are named explicitly rather than globbed: var/ holds other
things and must never be removed wholesale.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
The renamed-variable table mapped `matrix_bridge_hookshot_jira_oauth_uri` to
`..._jira_oauth_client_secret`, the entry above it. Anyone hitting the
deprecation was told to rename their setting to a variable that means something
else entirely; the URI's replacement is `..._jira_oauth_redirect_uri`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Both roles derived `..._appservice_database_uri` as `'sqlite:///' + <path>`.
mautrix-go hands that string to go-sqlite3 as a filename rather than parsing it
as a URL, so the bridge cannot open its database and dies at startup:
FTL Failed to initialize database
error="... unable to open database file: no such file or directory"
Every other mautrix bridge role here passes the bare in-container path.
This has stayed hidden because group_vars/matrix_servers selects postgres
whenever postgres is enabled, which is the default - so almost nobody reaches
the sqlite branch. Anyone who does gets a bridge that never starts.
Found by the mautrix-meta-messenger Molecule scenario, which runs sqlite
deliberately. The scenario's override is dropped and its assertion now compares
the rendered URI against the path the role defines, so the derived value is
what is under test rather than the scenario's own.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
`matrix_bridge_mautrix_discord_bridge_double_puppet_server_map_default` was
built from `matrix_bridge_beeper_linkedin_homeserver_domain` and
`..._homeserver_address` - a different role's variables, copy-pasted along with
the expression.
No user is affected today: group_vars/matrix_servers points both roles'
`homeserver_address` at `matrix_addons_homeserver_client_api_url` and both
domains at `matrix_domain`, so the rendered value is identical either way. It
only diverges for someone who overrides beeper-linkedin's homeserver settings,
where mautrix-discord would silently follow them.
It does not survive mautrix-discord being used without beeper-linkedin's
defaults in scope, which is how the Molecule scenario found it: with only the
one role loaded, the template fails on the undefined name. The scenario's
neutralising override is dropped in the same commit, so the expression is now
exercised rather than bypassed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
`tasks/main.yml` opens with a block tagged `reset-hookshot-encryption`, and
Ansible runs tagged tasks unless tags are actually selected. A run that selects
no tags therefore reaches `tasks/reset_encryption.yml`: on a host where the
service does not exist yet it fails outright, and on one where it does it stops
the bridge and resets its crypto store without being asked to.
Users of the playbook are shielded from this only because the documented way to
run it always passes `--tags=setup-all,start`.
Adding `never` makes the block reachable only when its tag is explicitly
selected, which is what `--tags=reset-hookshot-encryption` in
docs/configuring-playbook-bridge-hookshot.md already does - that keeps working
unchanged, as selecting a tag by name overrides `never`.
The Molecule scenario no longer needs its `skip-tags` workaround, which is what
makes this verifiable: the scenario runs with no tags selected, and is green
with the workaround gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Scenarios install their Galaxy dependencies with `force: true`, so two roles
running at once re-extract the same collections and roles into ~/.ansible and
pull them out from under each other mid-play. It surfaces as a collection that
was working moments earlier going missing:
the connection plugin 'community.docker.docker' was not found
Found while running five scenarios in parallel, where it cost a run.
ANSIBLE_HOME relocates both `collections/` and `roles/`, so one variable covers
both halves; the scenarios' ANSIBLE_ROLES_PATH workaround now follows it rather
than hardcoding ~/.ansible/roles. Left alone if already set, and unset in CI,
where each role runs in its own job and has nothing to collide with.
Verified by removing var/molecule-ansible-home entirely and running
matrix-alertmanager-receiver from cold: green through idempotence, with the
collections and roles landing under the per-role directory - which also shows
nothing was quietly relying on the shared ~/.ansible being populated.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
baibot is the first bot rather than a bridge, and the shape
differs from the appservices: it is a plain Matrix client that logs in with a
password, sets up its profile and then syncs. It publishes no port, so nothing
can be probed over HTTP; what it says about itself in the journal is the only
window into whether the role's configuration reached the process.
What the scenario proves:
- The unit is active with no automatic restarts, AND baibot got past startup
into its sync loop. The second half is what carries the scenario. baibot never
exits when startup goes wrong - it retries the failing step forever with a
growing delay - so the unit sits there `active` with `NRestarts` at 0 while
the bot is permanently half-started. Pointing `user.avatar` at a file that is
not there reproduces exactly that: the unit assertion still passes, the sync
assertion does not.
- The display name the bot announces it wants is the role's `user.name`, which
is neither the role's default nor what the stub reports the account already
has.
- The rendered `logging` string took effect per target: baibot's own records
appear at DEBUG (the role ships `info`) while everything underneath stays at
the `warn` catch-all. The second half is the control, and raising the
catch-all turns 2 DEBUG records into 161.
- The rendered config carries the scenario's homeserver, identity, command
prefix, admin patterns and user patterns, and uses password authentication
exclusively, with the access-token keys rendered as nulls.
- The statically-defined agent survived the provider templating - the
per-provider template rendered to YAML, parsed, merged and nested into the
list - key by key.
- The container runs as the uid/gid the playbook supplies (1234, not the 1000
the base image already has), on the image version defaults/main.yml pins, and
could write its session into the data path.
No AI provider is contacted and none is needed. baibot calls a provider only
when a message asks an agent to do something, so a static agent with a
placeholder key and a base URL that resolves nowhere still has to survive the
bot's startup parsing - which is the part worth testing.
The shared stub grew what a syncing Matrix client needs and an appservice did
not: /sync (with a `next_batch`, and holding the call open for the timeout the
client asked for, or the bot spins the stub in a hot loop), the media config
and upload endpoints a bot setting its own avatar insists on, /keys/upload with
its key counts, and filter creation. Without the media config in particular,
baibot never gets past profile setup.
The shared stub task gained a STUB_VERBOSE knob. The stub already advertised
the environment variable but there was no way to set it from a scenario, and
for a component with no port of its own its request log is the only place to
see what the component is actually asking for.
Note: molecule-shared/homeserver-stub.py also carries a loosened /login match
from another scenario being written in this same tree at the same time; it was
already in the working copy and is not mine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Slavi Pantaleev
renovate[bot]