chore: release 0.2.1 to main

day01 commented

2026-08-03 17:49:57 +00:00

Owner

Release of 0.2.1 to the production line.

Merge chore: release 0.2.1 (#23) into develop first. This pull request
tracks the develop branch, so it will pick the version bump up automatically.
Merging it before #23 would put VERSION=0.2.0 on main, and the tag guard in
build-image.yml refuses a v0.2.1 tag that disagrees with VERSION.

What lands on main:

reporting kept off the job critical path — the change measured as the 0.2.1
RC column in docs/benchmarks.md;
the job base image served from syncode.sh, same index digest as the mirrored
upstream, so the pin did not move;
crate::protocol renamed to crate::gitea_protocol;
registry build cache for release builds, so a run no longer rebuilds both
architectures from scratch after the per-run builder is destroyed;
documentation-only pushes and pull requests no longer build images;
superseded pull request builds are cancelled, and pull request builds export
nothing to the shared host;
the compatibility suite runs nightly instead of on a click;
the license names the SynCode authors, and the bundled hash-files.js has
recorded provenance.

Two of these only take effect once they are on main: the scheduled
compatibility run, because the forge detects schedules on the default branch
only, and the production job image base.

After this merges, the main build publishes main, latest and the commit sha.
Tagging v0.2.1 on that commit then runs the promote path, which copies those
manifests to runner:0.2.1 and runner-job:ubuntu-24.04-0.2.1 — no rebuild, so
the released images are byte-identical to the ones the main build verified.

The infra pins in meta follow once those tags exist.

Release of 0.2.1 to the production line. **Merge `chore: release 0.2.1` (#23) into `develop` first.** This pull request tracks the `develop` branch, so it will pick the version bump up automatically. Merging it before #23 would put `VERSION=0.2.0` on `main`, and the tag guard in `build-image.yml` refuses a `v0.2.1` tag that disagrees with `VERSION`. What lands on `main`: - reporting kept off the job critical path — the change measured as the `0.2.1` RC column in `docs/benchmarks.md`; - the job base image served from syncode.sh, same index digest as the mirrored upstream, so the pin did not move; - `crate::protocol` renamed to `crate::gitea_protocol`; - registry build cache for release builds, so a run no longer rebuilds both architectures from scratch after the per-run builder is destroyed; - documentation-only pushes and pull requests no longer build images; - superseded pull request builds are cancelled, and pull request builds export nothing to the shared host; - the compatibility suite runs nightly instead of on a click; - the license names the SynCode authors, and the bundled `hash-files.js` has recorded provenance. Two of these only take effect once they are on `main`: the scheduled compatibility run, because the forge detects schedules on the default branch only, and the production job image base. After this merges, the main build publishes `main`, `latest` and the commit sha. Tagging `v0.2.1` on that commit then runs the promote path, which copies those manifests to `runner:0.2.1` and `runner-job:ubuntu-24.04-0.2.1` — no rebuild, so the released images are byte-identical to the ones the main build verified. The infra pins in `meta` follow once those tags exist.

day01 added 25 commits 2026-08-03 17:49:57 +00:00

fix: keep control plane reporting off the job critical path

		The reporter drove the worker future from its own select loop and awaited
a control plane round trip on every StepStarted and StepCompleted event.
Both futures belong to one task, so each delivery suspended step
execution. A 20-step job spent 44 UpdateTask calls, and most of its wall
clock, waiting for the forge.

Report job state on a periodic tick instead of per step transition, and
drive the worker future while a delivery is in flight.

chore: drop redundant comments from the reporting loop

Merge pull request 'fix: keep control plane reporting off the job critical path' (#7) from fix/unblock-step-execution-during-reporting into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/7

docs: publish runner benchmark comparison

Merge pull request 'docs: publish runner benchmark comparison' (#9) from docs/benchmark-0.2.1-rc into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/9

ci: keep documentation changes out of image builds

		Documentation never reaches the images, yet a README edit invalidated the
source layer and rebuilt the whole workspace. Filter documentation-only
pull requests, exclude it from the main build scope and drop it from the
build context.

Pull request builds now export nothing: the images they produced stayed on
the shared host, and a cancelled build never reached the cleanup step.
Superseded builds are cancelled, because the host runs one job at a time.

chore: drop the unresolvable Renovate preset

		The config was inherited from the upstream runner and extends
`local>gitea/renovate-config`, which does not exist on this forge. Nothing
runs Renovate here either, so the file only claimed automation we do not
have.

docs: state the branch policy

		Pull requests target `develop`; `main` carries what production runs.

chore: drop comments that restate the workflow

Merge pull request 'ci: keep documentation changes out of image builds' (#10) from ci/trim-pull-request-builds into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/10

ci: cache release image layers in the registry

		Every release build created a fresh buildx builder and destroyed it on exit,
so the Cargo cache mounts and every layer were rebuilt from scratch for both
platforms. Keep the cache in the registry, which outlives the builder.

Verified against the SynCode registry on the runner host: a build with a
freshly created builder imports the cache and reuses the layers.

ci: skip develop builds for documentation-only pushes

		The dev environment pins the runner job image by version tag, not by commit
sha, so a documentation-only push produces no image anyone consumes.

Merge pull request 'ci: cache release image layers in the registry' (#11) from ci/cache-release-builds into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/11

ci: pull the job base image from syncode.sh

		The job image was built on a base served by docker.gitea.com. The mirrored
copy carries the same index digest, so the pin is unchanged.

ci: authenticate pull request builds against the registry

		The job base image now lives in the SynCode registry, which serves nothing
anonymously.

Merge pull request 'ci: pull the job base image from syncode.sh' (#12) from ci/job-base-image-from-syncode into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/12

ci: run the compatibility suite on a schedule

		The suite only ran when someone clicked it, and covered two features. It now
runs nightly, on pull requests that touch the workflow or cache adapters, and
still on demand.

New coverage: cache round-trip through the runner's cache API, matrix
expansion, job outputs consumed across jobs, expression functions including
hashFiles, and the vendor contexts a SynCode control plane exposes.

docs: claim the runner license and record the bundled asset

		The license file still carried the upstream runner's copyright, although no
Go source survived the Rust rewrite. What remains from Gitea is the vendored
protocol definition, which keeps its own license and pin next to it.

hash-files.js had no recorded provenance. It is an ncc bundle of the Actions
glob toolkit, identified by its module set and bundler signature.

Merge pull request 'docs: claim the runner license and record the bundled asset' (#14) from docs/license-attribution into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/14

ci: drop the SynCode context assertion

		The SynCode variable surface is deferred until the Gitea rewrite settles, so
the suite must not demand it. Issue #19 tracks it.

ci: drop the vendor context assertion

		The check only proved that the runner substitutes an alias from a lookup
table. Nothing there fails in a way the rest of the suite would miss.

ci: drop the matrix job

		It asserted that two keys of one include entry land in the same leg, but
never that both legs ran. A silently lost leg stayed green.

Merge pull request 'ci: run the compatibility suite on a schedule' (#13) from ci/schedule-compatibility into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/13

refactor: name the Gitea protocol re-export

		`crate::protocol` promised a neutrality the module does not have: it is the
Gitea Connect family, and the CLI maps only SynCode, Gitea and Forgejo onto it
while rejecting GitHub and GitLab. Every other re-export in lib.rs names what it
is.

Renaming now is a rename. After a second control-plane adapter it would also be
a migration of whatever grew on the ambiguous name.

Merge pull request 'refactor: name the Gitea protocol re-export' (#22) from refactor/name-the-gitea-protocol into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/22

day01 added 2 commits 2026-08-03 17:51:56 +00:00

chore: release 0.2.1

		The release carries the reporting fix that kept the control plane off the job
critical path, the job base image served from syncode.sh, and the named Gitea
protocol re-export.

Merge pull request 'chore: release 0.2.1' (#23) from chore/version-0.2.1 into develop

		Reviewed-on: https://syncode.sh/syncode/runner/pulls/23

day01 merged commit 8bfe74ca4a into %!s()

2026-08-03 17:52:16 +00:00

day01 referenced this pull request

2026-08-04 06:52:13 +00:00

chore: release 0.2.1 to main #29

chore: release 0.2.1 to main #24