OXYGENHUB

Releases 1

OxygenHub 0.4.1 v0.4.1 · ✔ signed by Andy McCall · andymccall ·

Trust and audit
  • The store as its provider's icon (issue #123). A repository kept in its owner's bucket shows the icon of Google Cloud Storage, Amazon S3 or Azure Blob Storage in its header; hovered, focused or tapped, a card gives the provider and, for its admins, the bucket, prefix, region and URL, with a link to Settings › Storage.

  • A tidier Projects page (issue #124). A filter and the New project button in one bar, Open and Closed tabs with their counts, a row per project with its board icon, privacy, number, last update and description; the new-project form opens above the list.

  • Making projects, and their references (issue #118, issue #119). The Projects page has a New project button for anyone who may make one, links to the organisations' boards from your own, and a Projects tab on every repository; a card or issue reference may name another repository (owner/repo#N). oh project lists, creates and edits boards (issue #115).

  • Blame of a conflicted file no longer fails (issue #120). Its conflict markers are lines no change wrote; the page gave an error, it now shows them with an empty blame cell.

  • Test reports (issue #114). A Flow job's JUnit XML artifact named junit is read like a coverage report: a Tests tab with each run's passes, failures and skips, every case's history, and the flaky ones. A failing job's artifacts kept with when "always" are shown too.

  • Pushes in parts. A long push from oxy 0.4.3 arrives as several requests, each of objects alone but the last; the hub stores each part and records the push once, when the last names the bookmark.

  • Memory under control (issue #116, issue #117). The cache of loaded states keeps to a size budget (OXYHUB_STATE_CACHE_MB, 3 GiB) as well as a count, the summary of a bookmark's heads is cached once per state, and the allocator returns freed memory; /health reports the cache.

  • A coverage check (issue #113). Each coverage report sets a coverage check, such as 81.9% (-0.3 against main), measured against the default bookmark. Settings › Coverage can set a minimum and a largest drop. The check then fails and says why, and as a required check it holds a proposal back. A proposal's report shows the files whose coverage moved against the default bookmark.

  • Coverage reports, built in (issue #113). A Flow job's artifact named coverage in LCOV format is read when uploaded, and the job's log says what it found. A Coverage tab shows the latest percentage and its change over a chart of every run, a strip of facts (lines covered, hits per line, functions, branches, files, badge with its Markdown), what this run changed and the files whose coverage moved, how files spread over coverage bands, a chart of covered and missed lines, the recent runs, every file with a bar, and each file's lines marked run or missed, as Coveralls does. A badge is at /OWNER/NAME/coverage/badge.svg, and the run page shows each job's coverage. Totals match cargo llvm-cov's own.

  • A wiki can start with a push. Someone who may write to a repository can push the first pages of its wiki to OWNER/NAME.wiki, as well as writing them on the web: the hub makes the empty wiki when a writer first reaches that address, and the push gives it its id. Readers still find nothing there until it has pages.

  • Mermaid diagrams in Markdown. A ```mermaid block in a README, wiki page, issue or proposal is drawn as a diagram, in the page's light or dark theme. The hub serves its own copy of Mermaid 12.1.0, loads it only on pages that have a diagram, and runs it in strict mode. A diagram that does not parse stays as its source, with the reason under it.

  • An organisation's storage policy (issue #96). An organisation's Settings › Storage can require every new repository to live in a bucket and list the buckets allowed, so its data stays where its own buckets are. The New repository form refuses anything else and says what is allowed.

  • A repository can live in its owner's bucket (issue #96). The New repository form has a Storage section: this server's disk, or your own Amazon S3, Google Cloud Storage or Azure bucket, with credentials for it. The bucket is checked before anything is made. The credentials are sealed on the server and used only for that repository. The hub keeps a cache in front. The header shows a bucket tag, and Settings › Storage checks the bucket again and replaces the credentials. Tested with a push into a real S3 bucket.

  • Runners decline, and the queue says why a job waits (oxygenflow#36, OxygenFlow spec §11.4–11.5). A runner can hand back a job it cannot run with a reason. The job is queued again and not offered to that runner while what it offers stays the same, for ten minutes at most. After three different runners decline it, the job ends as unplaceable with their reasons. Every 15 seconds the hub works out why each ready job no runner can take is waiting, from each runner's last claim: no runner online, a missing tier, the wrong architecture, an image it does not hold, a label, memory or CPUs, a scope, or a decline. The run page and the API show the reason, and a runner's page shows its tiers and what it declined.

  • Assistants through the API and oh (§13.4). List, add or change, and remove a repository's, an organisation's or the site's assistants, and read or set their prompts: /repos/{o}/{n}/assistants, /orgs/{org}/assistants, /admin/assistants; oh assistant list|add|remove|prompt with --org or --site. Tokens are write-only and read from an environment variable by oh.

  • Adding an assistant picks from what the provider offers (issue #109). A provider list fills the name, endpoint and API (with Other for anything else), List models fetches the endpoint's own models into the Model field, and a model the endpoint does not list is refused on save with ones it does. Administration is a sectioned page with a left-hand menu, its audit log paged (issue #110).

  • Agents get their marks, contributors one row each. A repository's contributors show one row per account with each agent's share beneath (↳ via Claude Code · 1), as oxy log does; agents' names on change pages, reviews and the ask buttons carry their brand mark (Claude, ChatGPT, Perplexity, DeepSeek, Mistral; Antigravity with the Gemini mark), served at /avatar/agent/{name}.

  • Jobs go to runners of the right architecture (oxygenflow#36). Runners report each image's architecture; the hub matches a job's arch or its image's against the runner's, and the queue says what a waiting job asks for.

  • Sign in with GitHub or Google (issue #106). Set up per provider under Administration (client id, sealed secret, on or off); the login page offers them. A first sign-in links the account with the same verified email, or makes an account when registration is open; connect or disconnect under Settings › Security.

  • Wikis (issue #104). Each repository can have a wiki: Markdown pages kept as an Oxygen repository of their own, read and edited on the web (with history, a sidebar, a page list and search) or cloned and pushed as OWNER/NAME.wiki. Web edits are signed changes, as code edits are. Settings › Advanced deletes the wiki data.

  • Advanced settings: transfer, archive, delete (issue #108). A repository's Delete section becomes Advanced: transfer the repository to a user or organisation (the old address redirects and oxy remotes keep working), archive it read-only with a reason and bring it back, delete it, and a placeholder for deleting wiki data ahead of wikis.

  • Accounts elsewhere on a profile (issue #105). Bluesky, Mastodon and GitHub under Settings › Profile, checked and normalised (a handle, @user@instance or a profile URL all work), shown on the profile with the service's icon as rel="me" links.

  • A job's identity: the hub is an OIDC issuer (issue #103). A job that declares identity "AUDIENCE" { mount-path … } gets a signed token naming the repository, bookmark, run and job, delivered as a file like a secret; /.well-known/openid-configuration and /.well-known/jwks.json publish what AWS, Google Cloud or Vault need to trust it. Tokens are masked in logs.

  • Secrets for pipelines (issue #107). Administration, organisation and repository settings hold secrets, typed once and sealed; a job gets only those its pipeline declares with secret, as files Flow mounts before it starts, never in the environment; their values are masked in the job's log as it arrives.

  • Variables for pipelines (issue #102). Administration, organisation and repository settings hold variables for OxygenFlow jobs, inner levels overriding outer, each page showing what it inherits; a claim carries the repository's effective set and Flow adds them to the job's environment under FLOW_* and the pipeline's own. Not for secrets, which Flow mounts.

  • AI assistants, step three: drafted descriptions (issue #97). The new-proposal form and an open proposal's editor have a draft-with button per assistant; the answer, written from the changes and diff, lands in the editor for the person to change before saving.

  • AI assistants, step two: review requests (issue #97). Under Reviewers, the author or a writer asks an assistant the repository may use; the hub sends it the proposal's title, description, changes and diff with the site, organisation and repository prompts, and records the answer as a comment review via the assistant, shown as "bob ↳ agent Claude". Approvals count only people, and an assistant's answer never replaces the asker's own verdict. Also POST …/proposals/{n}/review-requests in the API, with via on reviews.

  • AI assistants, step one: settings (issue #97). Administration, an organisation's settings and a repository's settings each hold a list of assistants (name, endpoint, API shape, model, extra headers, token, context budget, on or off) and a prompt. A repository sees its organisation's and the site's beside its own; the innermost of a name wins and one turned off above is off below. Tokens are sealed with ChaCha20-Poly1305 under keys/assistants.key and never shown again; TEST sends a one-line exchange. Review requests and drafted descriptions follow.

  • A runner's own labels and time limit (issue #98). A runner's page under Admin → Runners has a Settings form: labels an administrator gives it beside those it reports (jobs that ask for a label match either), and a job time limit in minutes below the site's, applied when it claims.

  • Mail settings on the admin page (issue #101). The SMTP URL and From address are set and saved from Administration, overriding hub.toml's [email], with a button that sends a test message to the administrator's own address; the password is kept on the server and shown masked. An empty URL turns mail off.

  • Spacing (issue #99, issue #100). The Add a runner button stands off the runners table and the webhook and collaborator forms fill their panel; a proposal's project entries keep a space before remove.

Assets