cqrenet/matrix-docker-ansible-deploy
6
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2026-09-19 14:20:10 +00:00
Code Issues Wiki Activity

Reword the Molecule scenario comments

Browse Source 
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
This commit is contained in:
Slavi Pantaleev
2026-08-27 18:02:53 +03:00
co-authored by Claude Opus 5
parent e2d3be504e
commit c447e1528b
32 changed files with 458 additions and 641 deletions
Download Patch File Download Diff File Expand all files Collapse all files
roles/custom/matrix-bot-baibot/molecule/default/converge.yml
+5 -7
View File
@@ -3,11 +3,9 @@
# SPDX-License-Identifier: AGPL-3.0-or-later
---
# The devture base roles carry the variables this role reads
# (`devture_systemd_docker_base_*`, `devture_playbook_help_*`), the same way
# they do when the playbook runs. `matrix-base` is deliberately NOT included:
# it does far more than this role needs, and what it would supply comes from
# molecule-shared/playbook-context.yml instead.
# The devture base roles carry the variables this role reads, the same way they do when
# the playbook runs. `matrix-base` is deliberately NOT included: it does far more than this
# role needs, and what it would supply comes from molecule-shared/playbook-context.yml.
- name: Include roles for matrix-bot-baibot Molecule tests
hosts: all
become: true
@@ -26,8 +24,8 @@
loop_control:
loop_var: role_name
# The role installs the unit but does not start it - in the playbook that is
# `systemd_service_manager`'s job - so the scenario starts it here.
# The role installs the unit but does not start it; in the playbook that is
# `systemd_service_manager`'s job.
- name: Ensure matrix-bot-baibot is started
hosts: all
become: true
roles/custom/matrix-bot-baibot/molecule/default/molecule.yml
+13 -20
View File
@@ -29,22 +29,18 @@ provisioner:
all:
matrix_bot_baibot_container_network: matrix-bot-baibot-molecule
# verify.yml runs as its own play, where the role's defaults are out
# of scope, so the paths it reads are pinned here as literals. They
# match what the role derives from matrix_base_data_path.
# verify.yml runs as its own play, where the role's defaults are out of scope,
# so the paths it reads are pinned here to match what the role derives.
matrix_bot_baibot_base_path: /matrix/baibot
matrix_bot_baibot_config_path: /matrix/baibot/config
matrix_bot_baibot_data_path: /matrix/baibot/data
# baibot is a plain Matrix client, not an appservice: it logs in with a
# password and then syncs, so a homeserver has to answer for it to get
# anywhere. prepare.yml stands up the shared stub for that.
# baibot is a plain Matrix client, not an appservice: it logs in with a password
# and then syncs, so a homeserver has to answer for it to get anywhere.
matrix_bot_baibot_config_homeserver_url: http://matrix.molecule.local:8008
# Deliberately different from the role's defaults (localpart `baibot`,
# name `baibot`, prefix `!bai`, self-introduction on) AND from baibot's
# own built-in defaults, so that a passing assertion cannot be explained
# by "it would have happened anyway".
# Deliberately different from the role's defaults AND from baibot's own, so a passing
# assertion cannot be explained by "it would have happened anyway".
matrix_bot_baibot_config_user_mxid_localpart: molecule-baibot
matrix_bot_baibot_config_user_name: Molecule baibot
matrix_bot_baibot_config_user_password: molecule_baibot_password_5b7c14
@@ -53,18 +49,15 @@ provisioner:
matrix_bot_baibot_config_access_admin_patterns:
- "@molecule-admin:molecule.local"
# `debug` rather than the role's `info`, so the journal carries what the
# bot loaded. verify.yml reads it.
# `debug` rather than the role's `info`, so the journal carries what the bot loaded.
matrix_bot_baibot_config_logging_level_baibot: debug
# baibot talks to AI providers, and a scenario must not need a provider
# account. It does not have to: providers are contacted only when a
# message asks an agent to do something, never at startup. So a static
# agent is defined with a placeholder key and a base URL that resolves
# nowhere. Nothing is ever called, and the agent still has to survive
# baibot's startup parsing of `agents.static_definitions` - which is
# what proves the role's provider templating produced something the bot
# accepts.
# A scenario must not need an AI provider account, and does not have to: providers are
# contacted only when a message asks an agent to do something, never at startup.
# So the agent below carries a placeholder key and a base URL that resolves nowhere.
# Nothing is ever called, yet the definition still has to survive baibot's startup
# parsing - which is what proves the role's provider templating produced something
# the bot accepts.
matrix_bot_baibot_config_agents_static_definitions_anthropic_enabled: true
matrix_bot_baibot_config_agents_static_definitions_anthropic_id: molecule-anthropic
matrix_bot_baibot_config_agents_static_definitions_anthropic_config_base_url: http://molecule-no-such-provider.invalid/v1
roles/custom/matrix-bot-baibot/molecule/default/prepare.yml
+6 -9
View File
@@ -31,9 +31,8 @@
docker_daemon_options:
storage-driver: fuse-overlayfs
# The role's file tasks set owner/group by name, and Ansible resolves those
# through the passwd database - so they have to exist before it runs. In a
# real deployment `matrix-base` creates them.
# The role's file tasks set owner/group by name, which Ansible resolves through the
# passwd database, so they have to exist first. `matrix-base` creates them for real.
- name: Ensure the matrix group exists
ansible.builtin.group:
name: "{{ matrix_group_name }}"
@@ -70,13 +69,11 @@
- matrix_bot_baibot_molecule_network.rc != 0
- "'already exists' not in matrix_bot_baibot_molecule_network.stderr"
# baibot logs in and then syncs forever; with no homeserver answering it
# never gets past login and the unit crash-loops. The shared stub is enough
# - see molecule-shared/homeserver-stub.py for what it is not.
# baibot logs in and then syncs forever; with no homeserver answering it never gets past
# login. The shared stub is enough - see molecule-shared/homeserver-stub.py for what it is not.
#
# It is told to claim the bot's own MXID, because the bot resolves who it is
# from what the homeserver hands back at login, and everything it does
# afterwards (its profile, its own-message filtering) hangs off that.
# Told to claim the bot's own MXID, because the bot resolves who it is from what the
# homeserver hands back at login, and its profile and own-message filtering hang off that.
- name: Ensure the homeserver stub is running
ansible.builtin.include_tasks:
file: "{{ lookup('env', 'MOLECULE_PROJECT_DIRECTORY') }}/../../../molecule-shared/tasks/homeserver-stub.yml"
roles/custom/matrix-bot-baibot/molecule/default/verify.yml
+37 -54
View File
@@ -12,10 +12,9 @@
gather_facts: false
tasks:
# The version is read out of the role's own defaults rather than pinned in
# molecule.yml, so that the assertion further down compares the running
# image against what defaults/main.yml actually ships. Pinning it here
# would make that assertion compare the scenario with itself.
# Read from the role's own defaults rather than pinned in molecule.yml, so the version
# assertion compares the running image against what defaults/main.yml ships.
# Pinning it here would make that assertion compare the scenario with itself.
- name: Load the role's defaults under a separate name
ansible.builtin.include_vars:
file: "{{ lookup('env', 'MOLECULE_PROJECT_DIRECTORY') }}/defaults/main.yml"
@@ -30,10 +29,9 @@
delay: 5
failed_when: false
# `Restart=always` means a crash-looping container still reports `active`,
# so the restart counter is checked alongside it. Asserted as `is defined`
# too, because `| int` turns a missing property into 0 and would pass
# vacuously on a systemd that does not expose it.
# `Restart=always` means a crash-looping container still reports `active`, so the restart
# counter is checked too. Asserted `is defined` because `| int` turns a missing property
# into 0 and would pass vacuously.
- name: Assert the service is active and has not been restarting
ansible.builtin.assert:
that:
@@ -47,17 +45,15 @@
automatic restart(s)
success_msg: "matrix-bot-baibot.service is active and has not restarted"
# baibot publishes no port of its own - it is a Matrix client, not a server -
# so what it says about itself has to come from its output. The unit runs
# `docker start --attach`, so `--log-driver=none` on the container does not
# stop the journal from carrying it.
# baibot is a Matrix client, not a server, so what it says about itself has to come from
# its output. The unit runs `docker start --attach`, so `--log-driver=none` does not stop
# the journal from carrying it.
#
# `Syncing..` is the line that matters, and it is what carries this scenario
# rather than the unit check above. baibot does not exit when its startup
# goes wrong: a profile step it cannot complete is retried forever with a
# growing delay, so the unit stays `active` with `NRestarts` at 0 while the
# bot never reaches its message loop. Point the avatar at a file that is not
# there and the assertion above still passes; this one does not.
# `Syncing..` is what carries this scenario, not the unit check above. baibot does not exit
# when startup goes wrong: a profile step it cannot complete is retried forever with a
# growing delay, so the unit stays `active` with `NRestarts` at 0 while the bot never
# reaches its message loop. Point the avatar at a missing file and the assertion above
# still passes; this one does not.
- name: Wait for baibot to reach its sync loop
ansible.builtin.shell:
cmd: >-
@@ -81,10 +77,8 @@
retrying profile setup
success_msg: "baibot got past startup and is syncing"
# `user.name` is the bot's display name. The scenario's value is neither the
# role's default (`baibot`) nor what the stub reports the account already has
# (`stub`), so the bot naming this as what it wants can only have come from
# the configuration the role rendered.
# The scenario's display name is neither the role's default nor what the stub reports the
# account already has, so the bot wanting it can only have come from what the role rendered.
- name: Assert the display name the role configured reached the process
ansible.builtin.assert:
that:
@@ -96,22 +90,19 @@
display name it wants, so `user.name` did not reach the process
success_msg: "baibot acts on the display name the role configured"
# The `logging` setting is one string carrying per-target levels
# (`warn,mxlink=info,baibot=debug`), so proving it arrived means proving that
# different targets ended up at different levels - a single global level
# would satisfy neither half of this.
# `logging` is one string carrying per-target levels, so proving it arrived means proving
# different targets ended up at different levels. A single global level satisfies neither half.
#
# First clause: baibot's own records appear at DEBUG, which the role's
# default of `info` would not produce.
# First clause: baibot's own records appear at DEBUG, which the role's default of `info`
# would not produce.
#
# Second clause is the control, and it is not vacuous: at DEBUG the crates
# underneath (matrix-sdk and its spans, hyper, eyeball) are extremely
# talkative - raising the catch-all level turns these two records into
# roughly a hundred. Their silence is the `warn` catch-all being enforced.
# Second clause is the control, and it is not vacuous. At DEBUG the crates underneath are
# extremely talkative, so raising the catch-all turns these two records into roughly a
# hundred. Their silence is the `warn` catch-all being enforced.
#
# A control on mxlink was tried first and is the trap here: mxlink happens to
# emit no DEBUG records at all on a first run, so asserting their absence
# passed just as happily with mxlink set to `debug`.
# The trap here: a control on mxlink was tried first, and mxlink emits no DEBUG records at
# all on a first run - so asserting their absence passed just as happily with mxlink set
# to `debug`.
- name: Assert the per-target logging levels reached the process
ansible.builtin.assert:
that:
@@ -150,10 +141,8 @@
vars:
matrix_bot_baibot_config: "{{ matrix_bot_baibot_config_file.content | b64decode | from_yaml }}"
# The role supports two mutually-exclusive authentication modes and refuses
# a configuration that sets both. This scenario uses the password mode, so
# the access-token keys must be rendered as nulls rather than omitted or
# left with a value.
# The role refuses a configuration that sets both authentication modes. This scenario uses
# password mode, so the access-token keys must render as nulls, not be omitted or set.
- name: Assert only the password authentication mode is rendered
ansible.builtin.assert:
that:
@@ -165,14 +154,12 @@
vars:
matrix_bot_baibot_config: "{{ matrix_bot_baibot_config_file.content | b64decode | from_yaml }}"
# The agent presets are the most involved templating in this role: a
# per-provider template is rendered to YAML, parsed, merged with an
# extension, and dropped into the list as a nested structure. This asserts
# the whole round trip, key by key.
# The agent presets are the most involved templating in this role: a per-provider template
# rendered to YAML, parsed, merged with an extension, nested into the list. Asserted as a
# whole round trip, key by key.
#
# No provider is ever contacted. baibot calls one only when a message asks an
# agent to do something, and the base URL here resolves nowhere on purpose -
# a scenario must not need an account with an AI provider.
# No provider is ever contacted. baibot calls one only when a message asks an agent to do
# something, and the base URL here resolves nowhere on purpose.
- name: Assert the statically-defined agent survived the provider templating
ansible.builtin.assert:
that:
@@ -215,10 +202,8 @@
{{ matrix_bot_baibot_role_defaults.matrix_bot_baibot_version }}
success_msg: "The running container is the version defaults/main.yml pins"
# The uid/gid come from outside the role (matrix-base supplies them in a real
# run, molecule-shared/playbook-context.yml here) and are deliberately not
# 1000, which the base image already uses - so this cannot pass by
# coincidence with whatever the image would have run as.
# The uid/gid come from outside the role and are deliberately not 1000, which the base
# image already uses, so this cannot pass by coinciding with the image's own user.
- name: Assert the container runs as the identity the playbook supplies
ansible.builtin.assert:
that:
@@ -228,10 +213,8 @@
({{ matrix_bot_baibot_container.stdout }})
success_msg: "The container runs as the uid/gid the playbook supplies"
# baibot keeps its session and crypto store here. The file existing proves
# the bind mount is writable by the user the container runs as - a
# read-only-root container whose data directory it could not write would
# never have got as far as logging in.
# baibot keeps its session and crypto store here. The file existing proves the bind mount
# is writable by the user the container runs as.
- name: Stat the session file baibot persists
ansible.builtin.stat:
path: "{{ matrix_bot_baibot_data_path }}/session.json"