WIP: integration branch (do not merge) by obbardc · Pull Request #96 · qualcomm-linux/pkg-linux-qcom

Christopher Obbard (obbardc) · 2026-09-03T03:12:13Z

Scratch branch where I stage work before splitting it into reviewable PRs.
Not for review or merge. Opened so the pipeline runs against the whole
stack; the individual PRs will follow and carry the discussion.

@v2

.github/workflows/Readme.md has listed this workflow as one of the two this repository runs for some time, and it was the one that was not here. Copied from qualcomm-linux/pkg-tftp-server, where it is already in use, so every repository running it runs the same file. It calls qualcomm/qcom-reusable-workflows' preflight orchestrator, enabling the semgrep scan, dependency review, repolinter, copyright and licence check and commit email check, and leaving the commit message check and armor checkers off. It runs on pull requests to main, on push to main, and on dispatch. security-events: write is what lets the semgrep results reach code scanning; the rest is read. Taken verbatim, including its @v2 reference to the orchestrator, which is the one floating ref left in this repository now that every action is pinned to a commit. That is deliberate here and worth stating: a compliance check is wanted at its current definition rather than frozen at the rules of the day it was added, and pinning it would quietly stop this repository receiving new checks. It is a Qualcomm-owned reusable workflow rather than a third-party action, and holding the file identical to its siblings is what makes it updatable everywhere at once. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Deprecated in so many words by 8a9e784, which took the nightly cron off it and gave that schedule to build-kernel-deb, leaving this one dispatch-only and waiting for somebody to notice. Its replacement has since been replaced again: build-kernel-deb split into build-kernel-debian and build-kernel-ubuntu, so the path it handed over to is two generations on. Nothing referenced it. It was the last caller of the qcom-build-utils build system -- its own kmake image from artifacts.codelinaro.org, its own build_kernel.sh and build-kernel-deb.sh, its own S3 layout under pkg/temp without a flavour in the path -- none of which any current workflow uses. It was also the last thing needing DEB_PKG_BOT_CI_TOKEN, and the last file in .github with unpinned actions before the pinning commits reached it, an invalid secrets: key under workflow_dispatch that actionlint rejects, and no permissions: block at all. build-kernel.sh stays. It is the packaging entry point build-kernel-ubuntu.yml runs, and shares nothing with this file but a name. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Every manual build already had to name something the matrix defines, but each workflow asked for it differently, and the two build workflows asked for things the matrix had long since taken over. daily.yml offered a Build scope dropdown whose three options -- full matrix, named builds, one flavour -- were three ways of writing a set of entries, one of which needed a second input to say which set. release.yml offered the same idea under a different name and a different default. build-kernel-debian.yml and build-kernel-ubuntu.yml offered neither: their dispatch predates one entry being one package, and still asked a person to type git-clone, srcpkg, binpkg, kernel-config, dkms and a Debian revision, with defaults frozen at whatever qcom-next/trixie looked like when the form was written. Dispatching one of those built whatever the form said, not what the matrix says, and nothing reconciled the two. So there is now one input, in the two workflows that resolve a matrix: builds, defaulting to all, otherwise a comma-separated list of names. A scheduled run carries no inputs and lands on the same default, which is what it wanted anyway. Selecting a flavour across its suites is naming its entries; the --flavour filter stays in resolve-matrix.py for local use. A name matching no entry of that delivery type still fails the run with the names that do, so a typo cannot quietly narrow a release. daily.yml is the manual entry point that build-kernel-* stops being. It resolves the selection into both families, so one dispatch can name Debian and Ubuntu builds together and each is called by the workflow that builds it -- which is the thing a dispatch of a single-family workflow could never do. The build workflows are workflow_call only now: one run of either is one matrix entry, and a reusable workflow cannot call itself to fan out over a list. The three inputs they offered that the matrix deliberately does not carry -- debug-build, qcom-next-pr, kernel-topics-pr -- move to daily.yml, where they apply to every selected build. They describe a one-off validation run rather than a delivery target, which is why they are inputs and not entry fields. The rest of what that form asked for is gone: it is in the entry, and typing it again was the way to disagree with it. resolve-matrix.py now rejects a build named all, which the dispatch form would otherwise read as every entry, leaving that build unreachable by name. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

A release was a second build. release.yml took a pinned tag, built it from scratch in a fresh CI workspace, and promoted that -- bits the daily build had already produced from the same tag and tested. Everything else followed from the duplicate build: a second set of matrix entries to describe it, a type field to tell the two sets apart, ref_strategy rules per type, a release ref pinned in a file so that releasing meant editing the matrix, and a revision convention whose only job was to keep the two builds' versions apart. What shipped was never quite the artifact that passed the daily. So the daily build now promotes. An entry naming a target_workspace is copied into it once its build succeeds, and release.yml promotes onward from there and builds nothing at all: it names a version that already exists and asks Debusine to publish it into the release workspace. lib/release was already built for this -- it promotes between workspaces given a source package and a version, and defaults its target to qli-staging. That collapses the matrix to one kind of entry, 15 to 11. type is gone, and with it the per-type ref and revision rules; target_workspace is now an optional field on any Debian entry rather than a Release-only one, and the entries that name none -- mainline, next, the topic branch -- are built for early warning and published to S3 exactly as before. Releasing changes no file here: there is no ref to pin, because the version being released has already been built. The trailing ~ therefore stays on the version through release. Promoting the tested artifact means the archive gets the version it was built with, and a release that dropped the ~ would have to be a different build, which is the thing being removed. Nothing new upstream is now a green run rather than a failure. The version is a function of the resolved ref and the entry's revision, so a night on which the tracked tag has not moved rebuilds a version the archive already holds and Debusine rejects the duplicate. prepare reads the version out of the changelog it just generated and asks the target workspace whether it has it, and the build, the S3 publication and the promotion are skipped when it does. An unreachable workspace fails the run instead: a configuration problem must not look like a quiet night. Three kinds of run promote nowhere by construction. A PR build never forwards a target-workspace. A dispatch setting debug-build, qcom-next-pr or kernel-topics-pr builds something the matrix does not describe, so build-kernel-debian.yml declines to promote it -- guarded in the callee, where it holds for every caller rather than for the ones that remembered. And an entry naming no workspace has nowhere to go. release-kernel-debian.yml is deleted. It was the release tail of a build that no longer happens. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Setting it broke the build. The input threaded from daily.yml through both family workflows into prepare-kernel-source, which turned it into --debug on the prepare-source.sh command line -- an option prepare-source.sh does not have, and whose argument parser rejects an unknown one outright. Anyone ticking the box on a dispatch got "Unknown option: --debug" and a failed prepare job, so the toggle has only ever been a way to break a run. Nothing is lost by removing it. A debug kernel is a flavour, not a run-time switch: qcom-next-debug builds the same ref with the in-tree debug fragments and packages it separately, so it installs alongside qcom-next and is built and published every night like anything else in the matrix. That is what the input's own help text already pointed people at. The promote job's guard loses a clause with it and keeps its meaning: a dispatch that overrides what gets built still promotes nowhere, and there are now two ways to do that rather than three. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

qcom-next-pr and kernel-topics-pr were dispatch fields on daily.yml, threaded through both family workflows to reach prepare-kernel-source. They described a kernel the matrix does not: a tree with pull requests merged or patches applied on top of the resolved ref, built at the same version as the nightly that has neither. Now that a build promotes into an archive, a one-off validation run reaching a dispatch field is a way to put an unreviewed tree in front of everyone who installs from it, so the fields go and the promote guard loses the clauses that existed to catch them. The action keeps both inputs and the steps that act on them. Merging a PR before building is still a real thing to want; it is simply no longer something a dispatch form offers, and a caller that wants it has to say so deliberately. daily.yml is left with one input, builds, which is the whole of what a manual run has to decide. The promote guard is now just target-workspace: pr-build.yml is the caller that names none, so a pull request's kernel still reaches no archive. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

target_workspace was a matrix field, so an entry said both what kernel to build and where the result belongs. Those are not the same kind of fact. What to build is a property of the kernel and belongs in the matrix; where it goes is a property of the run -- the nightly publishes to staging, a pull request publishes nowhere, a release publishes to production -- and the same entry takes all three paths depending only on which workflow picked it up. Keeping the destination in the entry forced the distinction to be encoded twice. The matrix carried it per entry, and every consumer then had to work around it: pr-build.yml had to remember not to forward the field, release.yml had to filter on it to find out which entries were releasable, and the resolver had to reject it on Ubuntu suites because only Debian has a promotion path at all. None of those were saying anything about a kernel. So the field is gone and each caller states its own destination. daily.yml names the staging workspace for its Debian legs, overridable through a DEBUSINE_STAGING_WORKSPACE repository variable. pr-build.yml names nothing, as before, so a pull request's kernel is still built and tested and still reaches no archive. release.yml takes from-workspace and to-workspace, defaulting to qli-staging and qli, and selects with --family debian rather than by looking for a field -- which is the real rule, since promotion runs through Debusine and only Debian is built there. One consequence worth stating: every Debian entry the nightly builds now reaches staging, mainline and next and the topic branches included. They were held out before by naming no workspace. Their packages are separate source packages under their own names, so they coexist there, and the Production gate on release.yml is what still decides that none of them reaches qli. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Every Debian build read "qli qli-staging" for its Build-Depends. That was right when a release was its own build from a pinned ref reading qli alone: the daily could resolve against staging because the thing that shipped resolved against released packages and would have failed if a dependency was missing there. Releasing by promotion removes that second build, and with it the check. The artifact a release publishes is now the one the nightly produced, so whatever the nightly resolved a Build-Depends against is what the released kernel depends on. Left alone, a kernel could reach qli needing a -dkms package that only ever reached qli-staging, and nothing in the pipeline would notice until someone tried to install it. So the workspace list becomes an input and each caller states its own. The nightly reads qli, because it is the build a release promotes. pr-build.yml reads qli and qli-staging, because nothing it builds is promoted anywhere and a kernel and the module it needs should be reviewable in one pull request. This is stricter than what the nightly had, so it will fail where the previous setting quietly succeeded: if a -dkms package the matrix lists has not been released to qli, the nightly build of every entry bundling it stops until it is. That failure is the point -- it is the released kernel's dependency that cannot be satisfied -- but it lands on the nightly rather than on a release, so expect it there first. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

release.yml promoted out of qli-staging into qli, which meant the pipeline needed qli-staging to exist at all: a workflow that runs days after the build has to read the packages from somewhere durable, and the workspace the build actually ran in is not that. lib/build names it <parent>-gh-<repo>-<run>-<attempt>-<leg> and creates it per run, so by the time anyone dispatches a release there is neither a name to look up nor, eventually, a workspace behind it. qli-staging was there to outlive the run. Promoting inside the build removes the need for it. build-kernel-debian.yml already had the promote job, reading the CI workspace while the run still holds it, so there was never anything for a second workflow to do that this one could not do first. release.yml is deleted, and with it the upstream-version field that existed only so a later run could name a version it had not built. The destination stays qli-staging for now. Nothing about where packages land changes with this commit: the same workspace receives the same artifacts from the same job, and only the workflow that could later move them onward is gone. Pointing DEBUSINE_STAGING_WORKSPACE at qli would publish every night straight into the released archive, so that is a decision to take separately, together with moving the promote job to the Production environment so an approval still stands between a nightly build and qli. README says so where the variable is documented. Nothing reads DEBUSINE_RELEASE_TOKEN any more, and the Production environment is unused. Both are left configured rather than removed, because they are what a gated promotion into qli will want. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The promote job in build-kernel-debian.yml runs when target-workspace is not empty, and pr-build.yml kept a pull request's kernel out of the archives by not passing the input at all -- relying on its default being empty, with the reason recorded in a comment two dozen lines above the block it applied to. That is a lot of weight for an absence to carry. A PR is unreviewed by definition and its packages are versioned -pr<number>, so promoting one would put a kernel nobody approved into an archive people install from, at a version no later build supersedes. Nothing in the with: block said so; a change to the input's default, or a copy of the block into a workflow that should promote, would have flipped it silently. So the value is written where it takes effect, with the reason next to it. Nothing changes at runtime: the input already defaulted to empty and still does. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The trailing ~ existed to sort a daily build below the release built from the same ref: two builds of one kernel needed two versions, and ~ is what made the daily the lesser of them. resolve-matrix.py enforced the pairing, requiring a Daily revision to be its Release revision plus a ~. There is no second build any more. A kernel is built once, and the artifact that build produced is what any archive holds, so nothing exists for a ~ to sort against. All it does now is make every published package look permanently provisional -- a version that will never be superseded by the non-~ one it implies is coming. So trixie builds at 0qli1~bpo13+1, forky at 0qli1, resolute at 0qli1~26.04.1. The remaining ~ in the trixie and resolute revisions is the backports convention and stays: it is what sorts a trixie backport below a forky build of the same kernel, and the cross-suite order the README documents is unchanged -- resolute < trixie < forky, verified with dpkg --compare-versions. Upgrades are unaffected. Every new version sorts above the ~-suffixed one it replaces, so a machine tracking qli-staging moves onto the next nightly by itself. The first run after this builds and publishes rather than skipping, because the version it produces is genuinely one the archive has not seen. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

pr-build.yml claimed that kver-extra marks the version so PR artifacts never collide with the daily build's. It does not: debian/rules appends KVER_EXTRA to KVER and derives the package version separately, so a PR build shares the nightly's source version and differs only in uname -r and the versioned linux-image name. That is enough where it is -- a PR build has its own throwaway workspace and promotes nowhere -- but it is not a version stamp, and the comment should not invite anything to start relying on it as one. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Releasing has had no workflow since the promotion was folded into the nightly build. That commit removed release.yml because its model could not work: it promoted out of qli-staging days after the fact, which meant the pipeline had to keep a durable staging workspace for it to read, since the workspace a build actually ran in is named after that run and does not outlive it. This one does not promote a previous run's build. It builds the ref it releases, in the same workflow the nightly calls, and promotes that build while the run still holds its workspace -- so what reaches qli is the artifact this run produced and tested, and the awkward dependency on a workspace outliving the run that filled it never arises. What is released is written down rather than typed in. ci/build-matrix.yaml gains a releases list beside builds: same shape, plus a target_workspace, and ref_strategy restricted to pinned_ref so that two dispatches of one entry cannot ship different kernels. Updating a release is a pull request that changes branch_or_tag, which puts the ref that ships under review before the run that ships it -- where an upstream-version dispatch field put it at the mercy of whoever typed it. The refs come from main, which is where releasing last worked: qcom-next and qcom-next-debug, trixie and forky, at qcom-next-7.2-20260826. target_workspace stays rejected on a builds entry. Where a nightly is published follows from why it is running and remains the calling workflow's to decide; a release is the one case where the destination belongs to the entry, because putting one ref into one archive is the whole of what it is. The two lists are validated together however few of them a caller selects, so a broken release entry fails a nightly run rather than lying in wait for whoever next tries to release. Releases are Debian-only, enforced rather than assumed: promotion runs through Debusine and the Ubuntu path has no workspace to promote into, so an Ubuntu entry there would name a destination nothing could deliver it to. Which environment the promote job runs in becomes the caller's, through a new promote-environment input defaulting to Staging. The nightly keeps promoting into staging unattended; a release passes Production, so whatever approval that environment requires stands in front of qli. The run summary lists the refs, revisions and destinations before that gate, so the approval is given against what is shipping rather than against a run number. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

prepare-kernel-source took qcom-next-pr and kernel-topics-pr and merged or applied them after the clone, but no workflow passes either: the build workflows have no input to carry them, so the two steps could never run. They could not have been wired up as they stood, either. The commit SHA and date are read from HEAD before the patches would be applied, so a patched build would name a commit it did not build. And a merge commit made at build time has no stable SHA, so the version could never be reproduced from it. An orig tarball keyed on the commit, which the source package is about to be, rules such builds out for good. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The action looked the revision up in ci/build-matrix.yaml when its input was empty, for a caller with no matrix entry in hand. No such caller exists: the build workflows are workflow_call only, are called with a matrix entry, and give the input a default of their own, so the lookup could not be reached. The revision is now a required input, and a caller that forgets it fails at the action boundary rather than building at a revision nobody chose. resolve-matrix.py keeps --field, which is still a useful way to ask the matrix a question from a shell. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The if: guards on the build jobs look removable, and are not: an empty matrix is a workflow error rather than an empty job list, so a family the run selects nothing on has to be skipped rather than started with nothing to do. Skipping one has a visible cost that looks like a bug. GitHub never expands a job it skips, so it cannot evaluate name: ${{ matrix.name }} and shows the expression's source text -- a check literally called "matrix.name". A || fallback does not help, printing its own source text just the same, and the only name that would read well is one never mentioning matrix, which would mean renaming every check in every workflow to tidy up one that appears when a family is empty. Both facts are written down so the next reader reaches that conclusion without rediscovering it. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Split out of "packaging: date debian/changelog from the kernel commit": the packaging half of that change landed early, alongside the reproducible source package work, before this action existed to call it. The action reads the date on the runner and passes it in, as it does the SHA and the ref: prepare-source.sh runs in a container as root and git will not read a checkout owned by someone else. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Every input naming what a build is -- the entry, its suite and flavour, the kernel repository and ref, the package names and the Debian revision -- had a default spelling out the qcom-next entry. No caller relied on one: daily.yml, pr-build.yml and release.yml pass all of them from the matrix. What the defaults did was let a caller that dropped one build the default entry's kernel under another entry's name without anything noticing. They are now required, so an omission is a workflow error at parse time. The inputs that keep a default are the ones for which empty is a value: tag-pattern outside latest_tag, an empty fragment or module list, and the overrides and destinations the caller chooses rather than the entry. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

prepare-kernel-source now runs build-source-package.sh after prepare-source.sh, in the same pkg-builder container, and uploads the resulting .changes set as source-package-<flavour>-<suite>. Nothing consumes it yet: the prepared-tree artifact is still uploaded and still what both build paths read, so this commit changes what a run produces and not what it builds. The next commits move each family onto it. The version the caller is told now comes from the fields file the script writes, read from the .dsc it built, rather than from a sed over the changelog on the runner host. The action also reports the orig tarball's name and SHA-256, which a caller can hold against what an archive already has for this upstream version. The container is told to trust the checkout, which the runner owns and root inside the container would otherwise refuse to read; it is this job's own clone. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The build job downloaded the prepared tree, unpacked it, and had debusine-action's generate-source-package assemble an orig tarball from it with tar czf -- a different tarball on every run. It now downloads the .changes set the prepare job built, reads the version from the .dsc, and gives lib/build that .dsc: the source package Debusine builds is the one prepare-kernel-source wrote and reported, with the reproducible orig. DEBUSINE_ASSEMBLE_ORIG in debusine-action stays for its other callers; nothing here uses it any more. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The build job downloaded the prepared tree and ran build-kernel.sh --local-source --skip-prepare, which had docker_deb_build.py make an orig tarball of its own with tar czf before handing sbuild a .dsc. It now downloads the .changes set prepare built and passes its .dsc to build-kernel.sh --dsc, which runs sbuild on it in the suite's pkg-builder image. The Ubuntu family therefore builds the same kind of thing Debusine builds for the Debian family: the source package the run reported, with the reproducible orig, and nothing is prepared twice. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Both build paths now start from the source-package artifact, so the tarball of the prepared tree has no reader. It was the larger of the two uploads, and the reason the README explained why an artifact had to be a tar.gz: the tree carried execute bits that upload-artifact's zip would strip. A .changes set is plain files, so that note goes with it, and the pipeline diagrams now show the source package as the handoff. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The orig tarball is now a function of the kernel commit, so the archive can hold a different one for the same upstream version only if something about how it was written differs -- and that is what this check is for. The already-published step, which already reads the target workspace's source index, now also finds every stanza naming this run's orig and compares its SHA-256 with the one prepare reported. A mismatch fails the run with both checksums, before anything is built, rather than surfacing as a file conflict at promotion or, worse, not at all. The case that matters is the packaging rebuild: 0qli1 to 0qli2 of one snapshot, where the archive requires the two revisions to share one file. The check reads this suite's index only, since apt indexes are per suite; across suites the reproducibility of the tarball itself is the guarantee. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The prepare job and the build job ran on the same runner label, so the only thing the artifact between them did was cross a job boundary that had no other reason to exist: uploaded by one ephemeral runner to be downloaded by the next. One job now clones, prepares, builds the source package and builds the binaries from it in place. The action still uploads the .changes set, as the record of what was built, but nothing downloads it. The build job's own image-fetch step goes with it. It repeated the action's pull-or-build decision for one suite; the action makes that decision for every suite before prepare-source.sh runs, and leaves the docker-pkg-build checkout where build-kernel.sh looks for it when it had to build the image. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The .deb files reach S3 under one run's directory; the source package they were built from now sits in source/ beneath it, on both paths. The .changes records every checksum, the .orig.tar.gz is the exact source, and the .dsc is enough to rebuild the packages anywhere. The Actions artifact holding the same files expires after a week; this is the copy that stays with the binaries. The Debian publish job downloads the artifact for it, since the source package was built on another runner; the Ubuntu job uploads it from the workspace it was built in. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The orig comparison ran first, so a night on which the tracked tag had not moved failed instead of skipping: the version was already published, and the orig in the archive predates git archive, so the checksums differ. That is a run with nothing to do reported as a conflict. A run that publishes nothing uploads no files, so nothing it built can conflict with anything. The already-published test therefore comes first and exits, and the orig comparison guards only a version that is actually going to be promoted. That leaves it doing the job it was added for: a packaging rebuild publishing a second Debian revision of one upstream version, where the archive requires both revisions to name one file. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

The action had a single caller and paid for being one. The vars and secrets contexts do not reach a composite action, so the Debusine host, scope, user and token were all declared as inputs whose only purpose was to carry values the calling workflow could already see. Its steps now sit in the build job and read vars and secrets directly, and six inputs and their plumbing go. Two more things fall out. The job checked out pkg-linux-qcom solely to reach the action, so that checkout goes too: the package comes from the artifact and the tooling from debusine-action, and nothing of this repository is needed in that job at all. And workspace_url was an action output that only ever fed a step summary, so it is now a local variable in the step that writes it. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

One Debian and one Ubuntu entry run while the source-package path proves itself against staging; the rest of the builds, and the whole releases list, stay commented out until it has. qcom-next-forky keeps the manual +staging1 revision that marks a build published there by hand. This replaces four WIP commits that reached the same state piecemeal -- disable everything, add the manual revision, comment the releases list back out, re-enable resolute. The tree is unchanged; only the history is. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>

Christopher Obbard (obbardc) self-assigned this Sep 3, 2026

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:18 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:19 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:20 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:21 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:26 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:34 — with GitHub Actions Error

github-advanced-security Bot found potential problems Sep 3, 2026

View reviewed changes

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:51 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 03:52 — with GitHub Actions Error

Christopher Obbard (obbardc) temporarily deployed to Staging September 3, 2026 04:00 — with GitHub Actions Inactive

Christopher Obbard (obbardc) temporarily deployed to Staging September 3, 2026 04:01 — with GitHub Actions Inactive

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 04:01 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 04:03 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 04:05 — with GitHub Actions Error

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 04:07 — with GitHub Actions Error

Christopher Obbard (obbardc) force-pushed the wip/obbardc/integration branch from 9773fea to 456a73a Compare September 3, 2026 06:21

Christopher Obbard (obbardc) temporarily deployed to Staging September 3, 2026 06:25 — with GitHub Actions Inactive

Christopher Obbard (obbardc) had a problem deploying to Staging September 3, 2026 06:26 — with GitHub Actions Failure

Christopher Obbard (obbardc) temporarily deployed to Staging September 3, 2026 06:27 — with GitHub Actions Inactive

Christopher Obbard (obbardc) added 28 commits September 9, 2026 22:59

Christopher Obbard (obbardc) force-pushed the wip/obbardc/integration branch from 71746e2 to c675b8a Compare September 9, 2026 22:42

Christopher Obbard (obbardc) temporarily deployed to Staging September 9, 2026 22:48 — with GitHub Actions Inactive

Navigation Menu

Uh oh!

WIP: integration branch (do not merge) - #96

WIP: integration branch (do not merge)#96
Christopher Obbard (obbardc) wants to merge 67 commits into
mainfrom
wip/obbardc/integration

Christopher Obbard (obbardc) commented Sep 3, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Christopher Obbard (obbardc) commented Sep 3, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants