flowchart LR
subgraph RU[r-universe, upstream, no badges here]
G[git.bioconductor.org<br/>maintainer push] --> CR[control-room<br/>hourly cron 41 * * * *]
CR --> SY[sync<br/>bioc · bioc-release monorepos]
SY --> BU[workflows/build.yml<br/>build + check]
BU --> API[r-universe API<br/>bioc · bioc-release]
end
API -- poll every 15 min --> OB[(observations<br/>R2 obs/…)]
OB --> GT{evaluate<br/>the gate}
GT --> R[(propagated index<br/>/repo)]
R --> F[freshness<br/>serves?]
R --> I[install<br/>installs?]
subgraph X[Experimental: standalone build path]
M[bioc-manifest<br/>validate] --> D[bioc-build<br/>dispatch → build-package → build.yml]
end
D -. attested tarballs .-> P[publish] -.-> GT
W[bioc-website<br/>site] -- static site --> R2[(R2)]
S[systemd bioc-sync<br/>bioconductor.org → R2] --> R2
R2 --> E[bioc-edge worker]
E --> H[health] & PA[parity] & L[bioc-website<br/>links]
CI & Scheduled Jobs
One page for the question “what is red, and does it matter?” Status badges are live. The table under Workflows is generated at site build by ci-inventory.py from the GitHub API, so it cannot drift from what actually exists; the description column is each workflow’s leading comment block, so a workflow with no header comment shows only its name. Everything else on this page is hand-written.
How the new-system workflows relate
The r-universe components are not ours and have no badge on this page. A stalled r-universe shows up here as freshness red on “latest observation under 36 hours”, since the registry polls its API and nothing else changes when r-universe stops. bioc-build’s build.yml is a pinned verbatim copy of r-universe’s, so the two build boxes run the same engine.Reading a red badge:
- publish red: the bioc-build → registry ingest broke. Experimental path; software packages from r-universe are unaffected.
- freshness red, publish green: the Worker is down, the observer stalled, or the served index is inconsistent (the #34 invariant).
- install red, freshness green: what the registry serves does not install. Since #47 the canary runs in the r-universe build image, so this is no longer “the runner lacks a system library”.
- health or parity red: the served site, not the data plane. Parity compares bioc-dev against production path by path.
- links red: link rot on the served site, a content problem.
Scheduled jobs outside GitHub Actions
The systemd --user timers on onclappc02, following the platform scheduling convention. There is no live status column: these alert on failure only (a GitHub issue or an ntfy push), and the heartbeat that would prove “ran OK today” is not set up yet.
| Unit | Repo | Cadence | What it does | On failure |
|---|---|---|---|---|
bioc-sync |
bioc-edge | hourly | Sync the bioconductor.org docroot to R2 | GitHub issue |
bioc-reconcile |
bioc-edge | weekly, Sun 04:00 | Checksum drift check: does R2 match the local mirror | GitHub issue |
bioc-logpush-check |
bioc-edge | daily 07:15 | Alert if yesterday’s Logpush access-log delivery to GCS is missing | GitHub issue |
biocintel-refresh |
bioc-intelligence | monthly, 1st 06:00 UTC | Enrichment pipeline: extract → link → enrich → marts → publish | ntfy |
Private repos with timers are not listed.
Workflows
The repos that make up the new system and its platform services, active workflows only. Dynamic workflows GitHub injects (Pages deploy, Copilot) are excluded; which repos appear is the GROUPS map in the script.
New system pipeline
bioc-edge
Serving side of bioconductor.org: Cloudflare Worker + R2 mirror
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
health.yml |
schedule, workflow_dispatch (17 6 * * *) |
Daily black-box probe of the serving stack at bioc-dev.cancerdatasci.org. The badge on this workflow is the status light: red means a probe failed. | |
parity.yml |
schedule, workflow_dispatch (52 6 * * *) |
Daily URL parity probe: does bioc-dev behave like production? (#1) The cheap early-warning between full cutover-diff.sh crawls: final status code, plus content-type major type on 200s, for a committed list of core paths and a… | |
test.yml |
push, pull_request | test |
bioc-infrastructure
How bioconductor.org is built, served, and being replaced — and the decisions behind it
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
docs.yml |
push, workflow_dispatch | docs |
bioc-registry
The Bioconductor package registry: metadata, propagated versions, installable artifacts, provenance, and build/check state behind one HTTP API
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
freshness.yml |
schedule, workflow_dispatch (43 6 * * *) |
Daily probe of the live registry: is the worker up, and has the observer actually observed something recently? The 15-minute poll previously had no alerting at all — a silent stop was detected by someone remembering to look. The badge… | |
install.yml |
schedule, workflow_dispatch (27 8 * * *) |
Daily installation canary: freshness.yml proves the registry serves; this proves what it serves actually installs into a real R session. The badge is the status light: red means the repo surface is broken for the pinned canaries. (#27) | |
publish.yml |
schedule, workflow_dispatch (7,37 * * * *) |
The bioc-build publisher (issue #13, SPEC-014). Sweeps completed build.yml runs on seandavi/bioc-build, verifies each staged package, and publishes it through the guarded POST /publish route — see scripts/publish.sh for the algorithm…. | |
test.yml |
push, pull_request | test |
bioc-website
Next-generation bioconductor.org: static Astro build fed by a data pipeline over primary sources (r-universe, the site git repo, the bioc-prop data plane)
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
links.yml |
schedule, workflow_dispatch (31 7 * * *) |
Daily link-rot check over the maintained pages of the served site. (#18) A fresh build enumerates the pages; the checks then run against the served dev host, where mirror-backed internal links resolve for real and external links are… | |
preview-cleanup.yml |
pull_request | Delete a PR’s preview build from R2 when the PR closes. | |
site.yml |
push, pull_request | Build the site and publish it to R2. push to main -> s3://bioc-site/site/ |
Platform services
bioc-intelligence
Research-intelligence & impact analytics for the Bioconductor ecosystem (DuckDB + Parquet, lake-sourced enrichment)
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
ci.yml |
push, pull_request | CI | |
deploy-pages.yml |
push, workflow_dispatch | Deploy Pages | |
frontend-ci.yml |
push, pull_request | Frontend CI |
Experimental
Prototypes of a standalone build path for the packages r-universe does not build (data-experiment, annotation, workflows; ADR 0010). Not the production route: software packages reach the registry from r-universe. A red badge here is not a production incident.
bioc-build
Bioconductor’s standalone package build system on GitHub Actions: configuration-driven build and check workflows for every package type, feeding the bioc-registry data plane
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
build-package.yml |
workflow_dispatch, workflow_call | Our entry point: resolves package+stream against seandavi/bioc-manifest into r-universe’s input shape (universe/repository/ref/…), then calls the mostly-verbatim build.yml engine with our_output set. See README.md “Relationship to… | |
build.yml |
workflow_call | Verbatim copy of r-universe-org/workflows/.github/workflows/build.yml Upstream: https://github.com/r-universe-org/workflows Pinned at commit 2025515d8de93f38f70bb8ff6384e06821a3b5bd (2026-09-03). Every uses: below is pinned to the… |
|
dispatch.yml |
workflow_dispatch | Manual-trigger-only for now: decides which (package, stream) pairs need a build and fans them out as a matrix of build.yml calls (issue #16, SPEC-014 §dispatch.yml). Never touches secrets; job 1 only reads public data (bioc-manifest,… |
bioc-manifest
Bioconductor build manifest: one YAML per package the build system is authorized to build, plus the policy file. The trust root; changes by human PR.
| Workflow | Status | Triggers | What it does |
|---|---|---|---|
validate.yml |
push, pull_request | validate |