Bud 1.2.0

Bud 1.2.0

Bud 1.2.0 adds access control with groups and policies, run notifications to Microsoft Teams, Slack, Discord or any JSON endpoint, an audit log, S3-compatible storage, Robot Framework runs through bud-runner, and report requests from Bloom.

Highlights

• Access control: permissions are grouped into policies and policies into groups, with a new developer role, separate Users and Access pages, and access requests from a run you may not open.
• Run notifications per channel to Teams, Slack, Discord or any JSON endpoint, optionally signed: every run, failures only, or the first failure after a green run.
• Audit log of security-relevant events, read under Audit log and pruned on the operator's schedule.
• S3-compatible storage for run artifacts and generated reports, with the local directory kept as a mirror. Local storage stays the default.
• Robot Framework runs from bud-runner 1.2.0 keep log.html and report.html with the run; every artifact is downloaded as an attachment under a sandbox policy.
• Report requests from Bloom, a company logo on PDF reports, and profile pictures.

Upgrade notes

• Back up the database and the uploads volume first. Migrations 017_release120 and 018_report_requests run from 1.1.0 (016_key_station_name). Migration 017 checks the 1.1.0 schema before it changes anything and stops with "Source schema fingerprint does not match its revision" when that schema was altered by hand. A downgrade below 017 is refused once the database holds what 1.1.0 cannot represent: execution requests, developer accounts, or group access that was changed or goes beyond Results.
• Only Test Stations submit execution results and upload artifacts: POST /api/uploads answers 403 for every user, admin included (1.1.0 accepted uploads from administrators). Move stations to bud-runner 1.2.0, which sends these with the station token even when a user session is configured.
• Links in emails (invitations, verification, password resets) and report links use APP_BASE_URL. FRONTEND_BASE_URL is still read, but only when APP_BASE_URL is not set; an install that sets both should check that APP_BASE_URL is its public address.
• S3 storage is optional: BUD_STORAGE_BACKEND=s3 (or STORAGE_BACKEND) with BUD_S3_BUCKET and the other BUD_S3_* settings listed in .env.example. python -m app.storage migrate --to s3 copies existing files.
• PyJWT replaces python-jose; boto3 and Pillow are added.

Compatibility

Component	Version
Container image	ghcr.io/mbedlabs/bud:1.2.0 (also 1.2, 1, stable)
bud-runner	1.2.0 for station-token uploads and Robot Framework, pytest and Behave runs
budtestlibrary	1.2.0
Bloom (optional)	1.2.0 for report requests

Added

• Report requests from Bloom appear for report publishers on the dashboard and run page, and notify active publishers through configured SMTP. Publishers fulfill requests through report publishing or refuse with a reason; status returns to Bloom.
• Company logo on test-run PDF reports: a user with settings.edit uploads a company logo in Settings; it renders on the report letterhead (top-left) alongside the EmbedLabs tamper-evidence footer, which is always present. The Settings preview loads through the authenticated client so the uploader sees exactly what was stored.
• S3-compatible object storage: STORAGE_BACKEND=s3 keeps run artifacts and generated reports in a bucket (AWS S3, MinIO, Hetzner, Ceph) under a per-instance prefix, with the local directory as a mirror that reads fall back to when the bucket does not answer (STORAGE_LOCAL_MIRROR, default on). python -m app.storage migrate --to s3 copies existing files and checks their sizes; cleanup reconciles the bucket; /api/ready reports the storage. Local storage stays the default and is unchanged. Adds boto3 to the locked dependencies.
• Robot Framework runs (bud-runner run-robot): HTML artifacts (text/html, Robot's log.html and report.html) are accepted. Every artifact download is an attachment sent with Content-Security-Policy: sandbox and X-Content-Type-Options: nosniff, so user-supplied HTML or SVG never runs in the Bud origin. The Bloom sync event says how many results had no Bloom tc_id and how many skipped results were not sent.
• Access control: permissions are resource.action pairs: evidence.view, reports.export, products.view, products.manage, stations.view, stations.manage, custom_runs.create, bloom_publish.execute, settings.view, settings.edit, audit.view, access.manage. A policy is a named set of permissions, a group is a named set of policies, and a user can be in several groups. A user's permissions are those of their role plus those of all their groups. Roles: viewer has the Results policy, developer also has Custom runs and Reports publishing, admin has every permission. 8 default policies and 5 default groups (Results Viewers, Test Operators, Station Managers, Access Managers, Application Administrators) are created; changing or deleting one returns 409, POST /{id}/duplicate creates an editable copy. A group containing stations.manage can only be given to admin or developer users (422). Only admin can give Application Administrators and change policies (403). A user with access.manage can only create, change, delete or give groups whose permissions they have themselves (403). User management and deleting runs and artifacts stay admin only. Access is not limited by product.
• Access endpoints: /api/policies (with /catalogue and /{id}/duplicate), /api/groups (policies, members, /{id}/duplicate) and GET /api/access/users. GET /api/auth/me returns the user's permissions.
• Separate Users and Access pages: /users manages accounts; /access, for admin and users with access.manage, provides Assignments with group rosters, Groups with policy bundles, Policies with a Read/Write editor and Requests.
• Run notifications: when a run finishes, Bud posts it to every enabled channel under Settings, Notifications: Microsoft Teams (an Adaptive Card for a Power Automate Workflows URL, a MessageCard for a classic connector URL, chosen from the URL), Slack (Block Kit), Discord (embed) or plain JSON for any endpoint. The message carries the run, product, station and software under test, the counts and duration, up to five failed tests, the Bud link and the Bloom link or sync failure. A channel sends all runs, failures only, or the first failure after a green run; its URL is stored encrypted and shown as a prefix; an optional secret signs the JSON body (X-Bud-Signature). Each delivery is attempted up to three times and recorded, shown as a notify stage on the run timeline; Send test message checks a channel. Routing per product and per station is not in this release.
• Audit log: security-relevant events (authentication, accounts, groups, station registration, enrolment keys and station removal, configuration, deletions, exports, imports, attachments) are recorded with the acting user, the request id, the client address, the outcome and details without secrets; a failed sign-in is recorded although the request fails. Users with audit.view read it under Audit log (GET /api/audit, filtered by actor, action, target, product, outcome and time). No endpoint changes or deletes an event; python -m app.audit prune --older-than-days N removes old events on the operator's schedule. Event times are shown in the viewer's time zone.
• Run access requests: a run that returns 403 or 404 shows a page with a Request access button (POST /api/access-requests, resource_type=test-run). Every admin and every user with access.manage gets an email with a link to /access. One request per user and resource per 24 hours. Requests are decided with POST /api/access-requests/{id}/decision. Requests and decisions are written to the audit log; if the email fails, the request is kept and the user is told.
• Publish to Bloom requests: a user without bloom_publish.execute sees Request access instead of Publish on a run (resource_type=publish-to-bloom). Granting requires a group_id of a group that has bloom_publish.execute and adds the user to it (422 otherwise).
• Database: migrations 017_release120 and 018_report_requests upgrade from 1.1.0 (016_key_station_name), including report requests. A database created by a pre-release 1.2.0 development image is converted as well: members of its development groups are moved to Test Operators (developer groups) or Results Viewers (viewer groups); the old group tables are kept and no longer used.
• Profile picture: a signed-in user uploads, replaces or removes their own picture under Settings, Account (PNG, JPEG or WebP up to 2 MB; stored as a PNG of at most 256 x 256 pixels without metadata, with the camera orientation applied). GET, PUT and DELETE /api/auth/me/picture; /api/auth/me reports has_profile_picture. Saved pictures appear in Users, the account menu, group memberships, audit actors and access requesters, with initials when none is stored. Replacing or removing a picture refreshes these identity views while preserving unrelated cached data.

Changed

• Custom Run stores a human execution request and shows its assigned station; the execution link appears when that station claims it. Only authenticated Test Stations create execution records, update their execution state, submit raw results and upload artifacts; POST /api/uploads returns 403 for every user, admin included. Queued requests do not appear as completed or pending executions in reports and dashboard totals. Dashboard totals classify claimed executions as in progress until the station acknowledges completion, and a nonzero exit or execution error counts as failure even when no method results were produced.
• Run page and PDF reports: a skipped assertion and an information entry (a Robot keyword that checks nothin...

1.1.0

Bud TMP v1.1.0

This release adds Cloudron packaging and first-run
setup, per-station enrolment keys, custom runs, PDF reports, and a link from
every run back to its Bloom suite.

Added

• Cloudron package — runs under Cloudron's read-only root filesystem with data and generated secrets in /app/data; PostgreSQL and local-storage addons, optional mail; minBoxVersion 9.1.0; CI smoke-tests the image against the Cloudron contract.
• First-run setup — GET /api/setup/status and POST /api/setup create the first administrator, hand over the runner registration key, and confirm by email.
• Per-station enrolment keys — minted on the Test Stations page, pinned to the first station that registers, shown once, stored as a SHA-256 digest. Stations are named at mint time and renamable.
• Custom runs — a test catalogue and Custom Run screen; a selection spanning two stations becomes one queued run per station; a station polls POST /api/runners/claim-run and executes the selected tests.
• Run ↔ Bloom link — a run links back to the Bloom test suite holding its synced test cases, shown on the run detail, the run list and the dashboard.
• Dashboard filters — by time range, Test Station and suite, plus run search and a location filter.
• PDF reports — GET /api/reports/test-runs.pdf (dashboard selection) and GET /api/reports/test-runs/{run_id}.pdf (single run), with download buttons on both screens.
• Run artifacts — list and download a run's files; the upload allowlist adds CSV, SVG, PDF, pcap/pcapng, gzip, tar, GIF and WebP (HTML stays refused).
• Release pipeline — tested images are promoted by digest to v1.1.0/1.1.0/1.1/1/stable; a published version is never overwritten; an SBOM is attached.

Changed

• Destructive actions (removing a station, revoking a key) confirm in a dialog; station row actions moved to a … menu, keys added with +.
• RUNNER_API_KEY removed from .env.example and the README; the teststations table and its endpoints removed; ALM renamed PLM.
• Transactional mail uses Bud's own colours; the frontend is split by route.
• Coverage measures threads and greenlets; the CI gate is 85%.
• Dependency updates — React 19, React Router 8, Node 24, and pinned backend dependencies; the audit carries no exception.

Fixed

• Constraint violations answer 409/422 with the request id; unhandled errors return the request id in the body.
• Run list search and the location filter apply on the server; latest_per_suite uses a window function.
• Summary tiles count test cases and assertions separately; counters exclude runs in progress.
• Cloudron mail uses the STARTTLS port; delivery failures return 503 naming host, port and TLS mode.

Security

• Revoking an invitation revokes its link.
• Result uploads authenticate with the station's own key; get_uploader_entity no longer reads the request body.

Upgrade notes

• Stations enrolled before 1.1.0 re-register once against a key minted by an administrator; RUNNER_API_KEY is no longer read.

Full changelog: https://github.com/MbedLabs/bud/blob/main/docs/CHANGELOG.md

1.0.0

Public release 1.0.0.