Phase 2b of the open-core hybrid extraction. After Phase 2a (PR #880)
wired the public-side loader to dynamic-import the private package,
this PR makes production Docker builds actually install the package
so the runtime path uses it. Single image; saelix/sencho remains the
only published image (the original ADR's dual-image plan was rejected
because customers buying paid tiers would otherwise need GitHub auth
to pull a second image, breaking the purchase flow).
Dockerfile (prod-deps stage): a new RUN block after npm ci installs
@studio-saelix/sencho-pro using a BuildKit secret-mounted github_token
for npm.pkg.github.com auth. The .npmrc carrying the token is written
and removed inside the same RUN, plus /root/.npm is wiped to scrub
any verbose-log artifacts that npm might otherwise stash. The token
never enters an image layer (BuildKit excludes secret content from
both layer filesystems and cache keys; docker history shows the
literal $(cat /run/secrets/...) command, not the substituted value).
PRO_PACKAGE_VERSION is a build arg pinned by CI to a literal SemVer
(0.1.0 today) so the scan build and the publish build resolve to the
same package version. Default of `latest` keeps local builds
convenient. When the pro package ships a new version, bump the value
in docker-publish.yml in the same PR that ships the matching public
Sencho release; release-please does not coordinate the two cadences.
Empty-secret branch (no github_token provided, e.g. local dev or
fork PRs) skips the install and prints a notice. The resulting image
runs through the loader's in-tree LicenseService fallback, so PR
validation builds and contributor builds work without any GitHub
auth setup.
docker-publish.yml: both build-push-action invocations (the
pre-publish scan and the multi-arch publish) pass the github_token
secret and PRO_PACKAGE_VERSION build arg. The auto-provisioned
GITHUB_TOKEN's packages:read scope is sufficient because the public
Sencho repo and the private package live in the same Studio-Saelix
GitHub org. Moving the package to a different org would silently
break this contract; the Dockerfile comment block records the
invariant.
ci.yml is intentionally not changed. The PR-time Docker validation
job builds without the secret and exercises the loader's in-tree
fallback path, which is correct for fork PRs (no token access) and
useful for catching fallback-path regressions.
Test plan: tsc clean (no TS changes). The dockerfile install path is
exercised by the next release's pre-publish scan + smoke test, both
of which boot the actual image and call /api/health. Failed dynamic
import or constructor throw would block bootstrap before the listener
binds, so the existing smoke test covers the runtime contract.
* chore(repo): enforce Conventional Commits via husky and commitlint
release-please parses commit subjects on main to compute the next version
and regenerate CHANGELOG.md. A non-conforming commit silently breaks both,
so the format must be enforced at commit time, not by review.
Adds husky 9 to wire a commit-msg hook, commitlint with the conventional
config, and a small rule override (loosen subject length to 120 chars,
disable subject-case so existing imperative subjects keep passing). The
prepare script runs husky on npm install so contributors do not need to
configure it manually.
* ci: add dependency-review workflow
GitHub-native action that diffs the PR's manifests (package.json,
package-lock.json) against main and fails when a new transitive dep
introduces a high or critical CVE. Existing vulnerabilities tracked in
security/vex/sencho.openvex.json and the Trivy scan in ci.yml are not
re-flagged here.
Pinned to actions/dependency-review-action v4.9.0 by commit SHA. Comment
summaries are posted to the PR only on failure to keep the conversation
clean on green PRs.
* ci: add stale workflow for issues and pull requests
Marks issues and PRs as stale after 60 days of inactivity and closes 14
days later unless re-engaged. Issues labeled pinned, security, bug, or
tracking are exempt and never auto-closed; PRs labeled pinned or security
are exempt. Runs daily at 01:30 UTC and processes up to 30 items per run
to stay within the action's rate budget.
Pinned to actions/stale v10.2.0 by commit SHA.
* chore(repo): route new issues to docs, discussions, and security policy
Disables the blank-issue option and adds three contact links the issue
chooser surfaces above the bug-report and feature-request templates:
docs.sencho.io for setup questions, GitHub Discussions for open-ended
chat, and the repository security policy for private vulnerability
reports. This keeps the bug tracker focused on actionable bug reports
and feature requests instead of support questions.
* ci(docker): publish multi-arch image to GHCR alongside Docker Hub
Mirrors every released sencho and sencho-mesh image to ghcr.io with the
same tags, signing, and supply-chain attestations as the Docker Hub copy.
Same content; pull from whichever registry your environment prefers.
- Adds packages:write to both publish jobs so the auto-provisioned
GITHUB_TOKEN can push to ghcr.io/studio-saelix/sencho and -mesh.
- Adds a second docker/login-action step authenticating to ghcr.io. The
Docker Hub login still resolves credentials from the production env.
- docker/metadata-action now lists both image references; one buildx push
attaches the manifest to both registries in a single round trip.
- Cosign keyless signing already loops over $TAGS, so adding the GHCR
reference is enough to sign both digests.
- The cosign attest step now loops over both registry paths so SBOM (CDX
+ SPDX) and OpenVEX attestations are resolvable from either registry.
Quickstart and image-verification docs note GHCR as an alternative pull
source with identical content.
* fix(mesh-sidecar): pin base image by digest
The main Sencho Dockerfile pins every base image by sha256 digest so a
republish of an upstream tag cannot silently shift content into a
release. The mesh-sidecar Dockerfile pinned node:22-alpine by tag, which
is exactly the gap that pinning closes.
Resolves node:22-alpine to its current multi-arch index digest (covers
linux/amd64 and linux/arm64) and threads it through both build stages
via a single ARG so a future digest roll only edits one line. The inline
comment documents the resolution command.
The sidecar holds an outbound websocket and has no inbound HTTP
listener, so adding a HEALTHCHECK is intentionally out of scope: a
process-liveness probe would be tautological with Docker's restart
policy. The Dockerfile now records that decision so it does not get
reopened on every audit.
* ci(docker): use repository_owner for GHCR login username
github.actor varies by event source (the maintainer who merged the
release PR on tag pushes, github-actions[bot] on bot-driven runs, the
dispatcher on workflow_dispatch). The username field is metadata only;
GITHUB_TOKEN is what authenticates against GHCR. github.repository_owner
resolves to a fixed value (studio-saelix) on every event and matches
GitHub's own example workflows for GHCR push.
* chore(repo): tighten commit subject-case rule
Disabling subject-case entirely allowed accidental ALL-CAPS or
PascalCase subjects through. Restrict to "never upper-case or
pascal-case" instead, which preserves the lowercase / kebab-case
norm of this repo and lets sentence-case subjects (used sparingly
on main) keep passing.
release-please-action v5.0.0 (release-please library 17.6.0) returns
exit code 1 when it tries to create a GitHub Release whose tag already
exists, even when the underlying state is consistent (release already
published, manifest current, label state correct). This causes the
action to abort before the "open or update release PR" step, leaving
new conventional commits unprocessed.
Adding workflow_dispatch lets a maintainer re-run the action manually
from the Actions tab once the inconsistent state is cleared (typically
by removing the autorelease label from the prior release PR), without
needing to push a no-op commit to main to retrigger.
The workflow's internal state checks still run on every dispatch, so
manual triggers cannot double-publish a release. release-please-action
is already at latest (v5.0.0, 2026-04-22) so a version bump is not an
option until upstream ships a fix for the duplicate-tag handling.
Lays the dormant data-plane foundation for Sencho Mesh. The pilot tunnel
gains TCP forwarding frames (tcp_open / tcp_open_ack / tcp_close JSON
plus a 0x04 TcpData binary type) and a TcpStream surface on the bridge
so a future MeshService can ride the existing WSS tunnel for cross-node
container traffic. The agent rejects every tcp_open with mesh_not_enabled
until a follow-up PR wires the Dockerode resolver gated by a
mesh_stacks opt-in table; ships dormant.
A new top-level mesh-sidecar/ package provides the per-node container
that will host the L4 forwarder + control WS in production. Built as a
small Node 22 alpine image and published in lockstep with the main
sencho image via a parallel docker-publish workflow job.
Tests cover protocol roundtrips on both packages and the sidecar
forwarder end-to-end including resolve, splice, close, and stats.
* feat(scaffold): fully automate release blog post publishing
Eliminates the manual PR-review step from the release blog scaffold pipeline.
The workflow now commits the generated post directly to sencho-website main.
scaffold-release-post.mjs changes:
- Remove renderPrBody and all body_file handling
- Update findLastAnchor to accept any post with a version: field, not just
category: release posts. This allows narrative retrospectives to anchor
the 5-release window.
- Add buildHeadline: generates a post title from the top two added items and
the total item count, e.g. "Sencho v0.69: Custom OIDC provider, Trivy
scanning, and 12 more"
- Add buildDescription: auto-generates a ~160-char SEO description from the
version range and top three added items
- Add calcReadingTime: estimates reading time from changelog word count
- Add coveredVersionsProse: formats "v0.65.0 through v0.69.0"
- Add updateMeta: inserts the new post into src/data/blog/meta.ts for
Worker-side SEO meta injection
- Remove the tmpdir/os import (no longer needed)
release-blog-template.tsx.tmpl changes:
- Replace all TODO placeholders with template variables (__TITLE__,
__DESCRIPTION__, __READING_TIME__, __COVERED_VERSIONS_PROSE__)
- Remove the screenshot placeholder section (auto-generated posts have no
screenshot; the intro links to docs.sencho.io instead)
release-blog-scaffold.yml changes:
- Remove permission-pull-requests: write from app token (no PR created)
- Replace "Commit and open draft PR" step with a simple git commit + push to
sencho-website main. No duplicate-check step needed.
- Include src/data/blog/meta.ts in the git add so the Worker SEO mapping
stays in sync automatically.
* fix(ci): use escapeTsxString in updateMeta to handle backslashes in blog post title and description
CodeQL flagged two high-severity alerts: title and description written
into meta.ts via updateMeta were only single-quote-escaped, leaving
raw backslashes unescaped. A value containing a backslash followed by
a special character would produce a malformed escape sequence in the
generated TypeScript source. The escapeTsxString helper already handles
both cases; use it consistently instead of an open-coded replace.
* fix(docker): build compose plugin from ./cmd, not ./cmd/compose
The compose-builder stage in Dockerfile was building ./cmd/compose, which
in docker/compose v5.1.2 is `package compose` (cobra command definitions),
not the CLI plugin entry point. `go build -o file pkg` against a non-main
package writes a Go archive; COPY and chmod accept it, but the kernel
cannot exec an ar-format file, so the Docker CLI plugin manager rejected
the binary and surfaced only as `docker: unknown command: docker compose`
in the v0.64.0 release smoke gate. The plugin's actual main package is at
./cmd (cmd/main.go calls plugin.Run from the cli-plugins framework), per
the upstream Makefile in v5.1.2.
Also fix the version ldflag to target the v5 module path: in v5 the module
moved from github.com/docker/compose/v2 to .../v5, so the previous
-X .../v2/internal.Version= silently no-op'd and `docker compose version`
would have reported an empty string even after the build target fix.
Add -trimpath and -s -w to match the upstream Makefile's release flags.
Add an inline ELF-magic sanity check inside the compose-builder stage so
this exact failure mode (non-main package emitting an archive) fails the
build at the producer instead of surfacing 200 lines later. Hex match via
`od -tx1` works on both busybox and GNU coreutils; the named-character
form (`od -c`) renders fields differently across the two.
Add a binary smoke step to the docker-validate PR job that mirrors the
release-time gate, so a regression in either the CLI or compose source
build is caught at PR review time rather than at tag-push time.
* fix(vex): match Trivy purl format for bundled docker/docker version
The compose plugin build target fix exposes a real consequence: now that
compose-builder produces a true ELF binary (rather than a Go archive),
Trivy can read the embedded Go module metadata and correctly reports the
bundled docker/docker dependency as `v28.5.2+incompatible`. The existing
VEX subcomponent ID omitted the `+incompatible` Go-module suffix, so
Trivy's purl matcher rejected the suppression and CVE-2026-34040 surfaced
in the docker-validate scan against the rebuilt image.
Update the @id to the literal version Trivy emits and bump the document
version per OpenVEX spec. The justification (compose acts as a CLI
client, never as a daemon, so the authz-hook path is unreachable) is
unchanged and continues to apply to v28.5.2+incompatible identically.
* docs(security): explain why CVE-2026-34040 cannot be upgraded out
A direct in-build upgrade attempt (`go get github.com/docker/docker@<sha
of docker-v29.3.1>`) fails with:
invalid version: go.mod has post-v1 module path
"github.com/moby/moby/v2" at revision f78c987a
moby/moby migrated its Go module path to `github.com/moby/moby/v2` on
the docker-29.x branch. The legacy `github.com/docker/docker` import path
is therefore frozen at v28.5.2+incompatible from Go's perspective; the
proxy.golang.org listing for that module path confirms no v29.x version
is resolvable. compose v5.1.2 (and v5.1.3, the latest tag at the time of
writing) both still import the legacy path, so the bundled docker/docker
library cannot be moved past v28.5.2+incompatible until upstream compose
migrates its imports.
Document the constraint in two places so a future maintainer (or future
me) does not re-attempt the same `go get` and arrive at the same dead
end:
- Dockerfile compose-builder stage: comment block above the build step.
- security/vex/sencho.openvex.json: expand the CVE-2026-34040 statement's
impact_statement to spell out the upstream module-split blocker. The
not_affected status (compose runs as a CLI client, never executes the
daemon authz hook code path) is the principled triage and remains the
correct OpenVEX call, not a deferred upgrade.
No build or runtime behaviour changes. Pure documentation enrichment.
* fix(security): mirror CVE-2026-34040 VEX statement in .trivyignore
Trivy reports `Some vulnerabilities have been ignored/suppressed` but
still fails the docker-validate scan on CVE-2026-34040, because the
OpenVEX statement's product identifier `pkg:oci/sencho` cannot match
the build-local image tag `sencho:pr-test`. Trivy does not generate an
OCI purl for images that lack a registry digest (aquasecurity/trivy
issue 9399), so VEX product matching is a no-op at PR and release scan
time. The dual-layer pattern documented in .trivyignore's header was
designed for exactly this case: VEX is the canonical, attested,
published triage record, and .trivyignore mirrors entries that scan-time
matching cannot resolve, with a comment pointing to the corresponding
VEX justification.
The CVE-2026-34040 OpenVEX statement is unchanged (status=not_affected,
justification=vulnerable_code_not_in_execute_path). The .trivyignore
entry is a build-time scan filter only, with a referencing comment so
auditors land on the VEX file as the source of truth. CVE-2026-39883
already follows this pattern and continues to.
* ci: add CodeQL analysis and Docker ecosystem to Dependabot
Add CodeQL workflow running javascript-typescript analysis weekly and on
every PR/push to main, using the security-extended query suite. All three
codeql-action steps are SHA-pinned.
Add the docker package-ecosystem to dependabot.yml so Dependabot opens
weekly PRs to bump Dockerfile digest pins (FROM node:22-alpine@sha256:...
and the golang builder stage) when upstream images are updated.
* ci(codeql): upgrade codeql-action to v3.35.2
v3.29.0 uses Node.js 20, which is deprecated on GitHub-hosted runners as
of April 2026, causing SARIF upload failures with "Resource not accessible
by integration." v3.35.2 runs on Node.js 24 and resolves the deprecation.
* ci(codeql): add actions:read permission for workflow run API
CodeQL v3.35.2 calls the GitHub Actions REST API to fetch workflow run
context for SARIF correlation, which requires actions:read. Without it,
the analyze step fails with "Resource not accessible by integration"
when calling /repos/{owner}/{repo}/actions/runs/{run_id}.
* feat(security): add SBOM attestations, VEX document, and retire .trivyignore
Add OpenVEX triage document (security/vex/sencho.openvex.json) for the 5
residual CVEs vendored inside docker/compose v5.1.2 that were carried over
from the previous PR. All 5 are marked not_affected with justifications.
Configure Trivy in both CI and release workflows to consume the VEX document
via trivy.yaml so the same source of truth gates PR scans and release scans.
Delete .trivyignore, which is fully superseded by the VEX file.
Add two new release pipeline steps after image publication:
- CycloneDX 1.6 SBOM via anchore/sbom-action (also installs syft)
- SPDX 2.3 SBOM via syft directly (reuses OCI layer cache from prior step)
Both are attached as cosign OCI referrer attestations (keyless, OIDC-signed)
and uploaded as GitHub Release assets alongside the OpenVEX file.
Bump docker-publish.yml permissions from contents:read to contents:write,
required for softprops/action-gh-release to create Release assets.
Add docs/operations/verifying-images.mdx with copy-paste verification
commands for all supply-chain artifacts: signature, SLSA provenance,
CycloneDX SBOM, SPDX SBOM, OpenVEX, and Rekor entry. Update docs.json
navigation and expand the Supply chain security section in docs/security.mdx.
Add a Verifying Release Artifacts section to SECURITY.md.
* fix(vex): cover otel SDK CVE-2026-39883 in rebuilt Docker CLI binary
The rebuilt Docker CLI v29.4.0 vendors otel/sdk v1.42.0, which still
contains CVE-2026-39883 (BSD kenv PATH hijacking; fixed in v1.43.0).
docker-compose v5.1.2 vendors otel/sdk v1.38.0 separately. The original
VEX statement only covered the compose binary's location and version,
so Trivy's scan of /usr/local/bin/docker was not suppressed.
Add a second subcomponent entry for the CLI binary path with the
correct vendored version. The not_affected justification (BSD-only
code path; we ship linux/amd64 and linux/arm64 only) holds for both
binaries.
* fix(ci): use list form for vulnerability.vex in trivy.yaml
Trivy's config schema requires vulnerability.vex to be a list (mapped
to the multi-value --vex flag). The previous bare-string value was
silently dropped, so the OpenVEX document was never loaded and HIGH
findings already covered by VEX statements still failed the scan.
* fix(ci): mirror VEX CVE in .trivyignore for local-image scan
Trivy does not emit an OCI purl for locally-built images without a
RepoDigests entry (aquasecurity/trivy#9399), so OpenVEX product
matching against the CI build target sencho:pr-test resolves to no
artifact and every statement is silently dropped. The VEX document
remains the canonical triage record and is still attached as a cosign
attestation on the published image; this file just mirrors the single
CVE that surfaces on the local scan so CI does not block on a finding
already triaged in VEX. Updates the Trivy step comment to document
the relationship between the two files.
* feat(security): rebuild Docker CLI/Compose from source, pin base image digests
Build Docker CLI v29.4.0 and Compose v5.1.2 from source against Go 1.26.2
to resolve 7 CVEs that were accepted in .trivyignore:
- CVE-2026-32280/32281/32282/32283/33810: Go stdlib x509/TLS and DNS
issues in the upstream static CLI binary (compiled with Go 1.26.1).
All fixed by rebuilding with Go 1.26.2.
- CVE-2026-33186: grpc 1.78.0 in Docker CLI. Eliminated from the SBOM
by building with the patched Go toolchain and updated module graph.
- CVE-2026-33671: picomatch ReDoS in npm bundled with node:22-alpine.
Resolved by removing npm/npx from the runtime image entirely (npm is
only needed at build time).
Remaining 5 entries in .trivyignore are vendored deps inside Compose
v5.1.2 (buildkit, moby/docker, otel) that cannot be patched without an
upstream Compose release. These will be expressed as OpenVEX
not_affected statements in the follow-up PR (feat/security-sbom-vex).
Also in this commit:
- Pin all Dockerfile FROM lines to @sha256: digests (node:22-alpine,
tonistiigi/xx, golang:1.26-alpine) to prevent silent base image
changes between scan and publish.
- SHA-pin all GitHub Actions in docker-publish.yml and ci.yml that
were previously referenced by mutable @vN tags.
- Add a binary version smoke test to confirm docker/compose produce
expected output before the multi-arch push proceeds.
* fix(docker): fix cli-builder vendor mode and compose-builder cache path
docker/cli v29.4.0 uses CalVer and ships vendor.mod instead of go.mod,
so plain `go build` fails with "cannot find main module." Fix: copy
vendor.mod -> go.mod and vendor.sum -> go.sum before building, then
pass -mod=vendor so all deps come from the vendored tree with no network
access. Cache mount is not needed with vendor mode and is removed.
compose-builder used /root/go/pkg/mod as the cache mount target, but
golang:alpine sets GOPATH=/go, so the module cache lives at /go/pkg/mod.
The wrong path caused a silent cache miss on every build. Corrected.
Updates the backend listen port, Vite dev proxy target, Docker EXPOSE,
compose port mapping, .env.example default, GitHub Actions smoke-test
default, healthcheck URLs, and every doc/example reference. Test fixtures
that include example URLs were updated for consistency, though their
assertions are port-agnostic.
The rate-limit value of 3000 in middleware/rateLimiters.ts and the
3000 entry in WEB_UI_PORTS (which detects user containers like Grafana)
are intentionally untouched.
Adds a workflow that fires on every v* tag push, computes the window
since the latest release post's anchor version in the sencho-website
repo, and (when the window reaches 5) opens a draft PR in
sencho-website with a fully pre-filled scaffold: grouped
ChangelogSection blocks parsed from CHANGELOG.md, version field set to
the new anchor, and a checklist body covering intro, screenshot, docs
link, and reading time. No auto-publish; the human writes the
narrative.
Uses the same sencho-token-app GitHub App as release-please, with its
installation extended to include sencho-website.
Replace the long-lived DOCS_REPO_TOKEN personal access token with
short-lived installation tokens minted per-job from the sencho-token-app
GitHub App (owned by the AnsoCode org, installed on both Sencho and
sencho-docs).
Why this is better than the PAT:
- Scoped per-job to only the repo the job actually touches, not one
token that works everywhere. update-screenshots and release-please
mint against Sencho; sync-docs mints against sencho-docs.
- Scoped per-job to only the permission scopes the job actually needs
(contents:write and sometimes pull-requests:write), not the broader
scope a PAT carries.
- Auto-revoked at job end by the action's post-run step, so a leaked
log line or artifact is useful for at most the remainder of that job.
- Not tied to any individual user account: no more risk of the token
silently dying when the human who minted it leaves or rotates keys.
- Like a PAT but unlike GITHUB_TOKEN, installation tokens DO trigger
downstream workflow runs, so the release-please tag push still
cascades into docker-publish.yml exactly as before.
Jobs migrated:
- release-please.yml: single mint, passed to release-please-action.
- ci.yml update-screenshots: one mint reused by checkout, peter-evans
create-pull-request, and the gh pr merge step.
- ci.yml sync-docs: one mint targeting sencho-docs, fed to the git
clone URL as x-access-token.
DOCS_REPO_TOKEN can be deleted from repo secrets after the first full
release cycle under this migration validates release-please,
update-screenshots, and sync-docs all succeed end-to-end.
actions/create-github-app-token pinned to v3.0.0 at SHA
f8d387b68d61c58ab83c6c016672934102569859, consistent with the
SHA-pinning convention established in the supply-chain hardening PR.
The runtime stage's `apk upgrade --no-cache` layer was being reused from
the buildx gha/registry cache indefinitely, so newly-patched Alpine
packages (e.g. openssl CVE fixes) could sit behind a stale layer until
an unrelated Dockerfile change invalidated it by coincidence. This
surfaced as Trivy hard-failing on CVE-2026-28390 (libcrypto3/libssl3
DoS in CMS) on the github-app-token-migration PR, even though upstream
Alpine had already published 3.5.6-r0 with the fix.
Add an APK_CACHE_BUST build-arg that CI sets to the current UTC date
(YYYY-MM-DD). Each calendar day the arg value changes, which changes
the RUN layer's hash, which forces buildx to re-execute `apk upgrade`
and pick up whatever Alpine has published that day. All three build
invocations (PR docker-validate, release pre-publish scan, release
multi-arch push) pass the same value, so the scan and the published
artifact always share a layer and Trivy never scans stale bits.
Default value `unset` lets local developers `docker build` without
the arg; production CI always supplies the date.
The Playwright browser download (Chrome for Testing + Chrome Headless
Shell + FFmpeg, ~170MB total) is the single largest cost in the
start-app composite action. Observed in a recent E2E run: 4m15s to
download cold vs ~10s on a warm cache. Across weekly cache evictions
and the ~30% of runs that hit a cold cache, that is multiple action
minutes per PR averaged over time, and several minutes of wall-time
regression on any individual cold run.
Split the existing `playwright install --with-deps chromium` step
into two halves:
1. `playwright install-deps chromium` runs unconditionally because
apt packages live under /var and are not preserved by actions/cache.
This is fast (~10s).
2. `playwright install chromium` runs only when the browser cache
under ~/.cache/ms-playwright misses. The cache key is pinned to
the @playwright/test version read from the root package.json, so
a future bump invalidates the cache automatically and the old
browsers are replaced cleanly.
Sharding (the other half of the original optimization plan) was
evaluated and rejected. With ~80s of per-job setup and only ~60s of
test time, 2-way sharding would roughly double action minutes while
saving only ~5s of wall time on warm runs. The math only pencils out
when test time significantly exceeds setup time, which is not the
case for Sencho today. Revisit if the suite grows past ~5 minutes
of pure test time.
The backend CI job already runs `tsc` against backend/src/ and only
marks the job green after build + tests + lint + audit all pass. The
E2E job then checked out the same source and ran the same tsc again
inside the start-app composite.
Upload backend/dist/ as a 1-day retention artifact at the end of the
backend job, download it in the E2E job before invoking the composite,
and gate the composite's "Build backend" step on a new
`skip-backend-build` input. The update-screenshots job (which also
uses the composite but has no upstream backend job) leaves the input
at its default of 'false' and continues to build from source.
Savings are modest (~10-15s per E2E run, on top of what setup-node's
~/.npm cache already buys us) but the real win is the contract:
the dist/ that E2E exercises is now byte-for-byte the same artifact
that the backend job verified, eliminating a whole class of "works
in backend job, breaks in E2E" drift.
Starts the already-loaded localhost/sencho:release-scan image headless
on the runner and polls /api/health for up to 30 seconds. Catches
entrypoint regressions, native module ABI breakage, and first-boot
crashes on the exact artifact that the multi-arch push step below
will republish moments later.
Placed BEFORE the build-push step so a smoke failure does not move
the `latest`, semver, or minor tags on Docker Hub. The image reused
here is the same amd64 artifact Trivy scanned a step earlier, so
there is no extra build or pull on the critical path.
The container is started without --rm so that docker logs in the
trap can surface the stack trace when the container crashes during
boot; the trap force-removes it after capturing logs whether it
exited or is still running.
/api/health is public and returns before any DB, JWT, or Docker
socket work, so no env vars, volume mounts, or bind mounts are
required for the smoke test to be a valid signal that the process
booted and the HTTP server is accepting connections.
Skip the backend, frontend, docker-validate, and e2e jobs on the
chore/refresh-screenshots auto-PR opened by the update-screenshots job.
Screenshot PRs only touch docs/images/ and cannot affect build, lint,
or test surfaces, so running the full PR CI suite on them burns ~6
action minutes per release for zero signal. This mirrors the existing
release-please--branches--main--components--sencho skip.
Also short-circuit sync-docs: when a push to main does not touch any
file under docs/, skip the clone, rsync, and commit steps. rsync
--delete would be a no-op anyway, but spinning up the runner and
cloning sencho-docs still burns ~30s per non-docs merge, which adds
up across multiple merges per day. Requires fetch-depth: 2 so the
detect step can diff HEAD~1 HEAD.
Finally, correct the scan-build comment in docker-publish.yml: the
push-build's amd64 leg reuses layers from the buildkit daemon's
in-memory cache (same job, same daemon), not from the shared registry
buildcache. The cache-from pull is a cold-start fallback for the
first-ever run.
* ci: hard-fail PR and release scans on unacknowledged HIGH/CRITICAL CVEs
Make Trivy a real gate instead of an advisory signal:
- PR CI (docker-validate) no longer uses `continue-on-error: true` on the
Trivy step, so any HIGH/CRITICAL finding not in `.trivyignore` fails the PR.
- The release pipeline (docker-publish.yml) now builds an amd64-only scan
image into the local daemon before the multi-arch push-build, re-runs
Trivy against that exact artifact, and only proceeds to the push if the
scan passes. This closes the gap where a CVE landed between PR merge and
release-time rebuild.
- New `.trivyignore` at repo root is the single source of truth for
acknowledged CVEs across both workflows; it starts empty so the first CI
run surfaces the full list, which we then populate with justifications.
* ci: populate .trivyignore with initial HIGH/CRITICAL acknowledgements
First CI run on the hard-fail Trivy policy surfaced 7 unacknowledged
findings. Each has been reviewed and justified inline:
- 6 CVEs in the statically-linked Go modules inside docker-compose v5.1.1
(github.com/docker/docker, buildkit, otel/sdk x2, grpc). These are
transitively bundled and cannot be bumped without an upstream Compose
rebuild. The grpc CVE is already explicitly acknowledged in the
Dockerfile rationale block at Dockerfile:108-111.
- 1 CVE in picomatch 4.0.3 bundled inside the npm CLI that ships with
node:22-alpine. npm is only invoked at build time against our own
package.json, so the ReDoS vector is not reachable.
Every entry has a revisit trigger (next Compose release or next Alpine
node bump).
Pin the push_to_registry job to a GitHub `production` environment so the
DOCKERHUB_USERNAME and DOCKERHUB_TOKEN credentials can live there
instead of as repo-wide secrets. Any future workflow that tries to push
to Docker Hub without declaring this environment will fail to resolve
the credentials, which is exactly the blast-radius reduction we want.
As a side benefit, adding a required reviewer to the `production`
environment in repo settings now turns every release into a manual
approval gate with zero workflow changes. The secrets were already
moved into the environment ahead of this commit, so the next release
run will pick them up seamlessly.
When an E2E test flakes in CI, the backend and frontend stdout is gone
the moment the step exits. That makes a failed run extremely hard to
triage: you get the Playwright report but nothing from the services
underneath it. Redirect both dev servers to files under the workspace's
ci-logs/ directory and include that directory in the failure-case
artifact upload, so the report and the service logs travel together.
Log files live under $GITHUB_WORKSPACE rather than /tmp because
actions/upload-artifact@v4+ computes a common parent directory across
all path entries. Mixing repo-relative paths with /tmp paths makes '/'
the common root, which v4+ then strips from the artifact, silently
dropping the absolute entries. Keeping everything under the workspace
avoids that footgun.
`stdbuf -oL -eL` forces line-buffered output on both services. Node
stdout is block-buffered when redirected to a regular file, so a crash
or abort can lose the final few hundred lines - exactly the output you
need when debugging a CI failure.
Also remove the duplicated `E2E_USERNAME: admin` / `E2E_PASSWORD:
password123` env blocks from the e2e and update-screenshots jobs.
Those values were already the fallback defaults in e2e/helpers.ts
(`process.env.E2E_USERNAME ?? 'admin'`), so the env blocks were doing
nothing on the default path and created two sources of truth for the
same literals. e2e/helpers.ts remains the canonical source; callers
that want to override the creds still set E2E_USERNAME / E2E_PASSWORD
as job-level env.
Every published Sencho Docker image is now signed with Sigstore cosign
using GitHub Actions keyless OIDC, and ships with an embedded SBOM plus
SLSA provenance attestation attached as OCI referrers on the image.
Users can verify the signature and inspect the attestations themselves
before pulling an image into production.
cosign verify saelix/sencho:<tag> \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com
The release pipeline now also publishes a new moving minor tag
(saelix/sencho:X.Y, e.g. 0.42) alongside the existing latest and
immutable X.Y.Z tags, so operators who want the latest patch on a given
minor line can pin without chasing every release. Since every 0.x minor
is potentially breaking, the {{major}}-only tag is deferred until 1.0.
cosign is installed via the sigstore/cosign-installer action pinned to
a full commit SHA. The signing step batches every tag produced by
metadata-action into a single cosign invocation pinned to the built
digest, so all tags resolve to the same manifest and we save N-1
Rekor/Fulcio round trips. The job declares id-token: write so the
ambient OIDC token can be minted.
A new docs page (docs/reference/verifying-images.mdx) walks users
through installing cosign, verifying an image, and inspecting the SBOM
and provenance with docker buildx imagetools. A note calls out that
signatures start shipping with v0.43.0, so older images failing
verification is expected behavior and not tampering.
Pin three third-party actions to full commit SHAs with version comments
so dependabot can update them in place without exposing the pipeline to
upstream tag tampering:
- aquasecurity/trivy-action@v0.35.0
- peter-evans/create-pull-request@v8.1.1
- googleapis/release-please-action@v4.4.0
Add a workflow-level permissions: contents: read default to ci.yml, with
update-screenshots keeping its explicit contents: write + pull-requests:
write override. Add the same default to docker-publish.yml (single job).
Expand .dockerignore to explicitly exclude .env*, *.key, *.pem, .github/,
docs/, website/, e2e/, tests/, test-results/, and playwright-report/ as
defense in depth against accidental build-context leaks. None of these
paths are read by any COPY step in Dockerfile.
* ci: optimize workflows to cut redundant runs and add timeout protection
Skip validation jobs (build, test, lint, Docker, E2E) on push-to-main
since code was already validated on the PR. Skip CI entirely for
release-please PRs (version bump only). Add timeout-minutes to all jobs
to prevent hung runners from burning 360 min (GitHub default). Add npm
caching to the start-app composite action. Add concurrency control to
docker-publish. Group Dependabot updates to batch PRs per ecosystem.
Estimated savings: ~10 min per release cycle, ~30-40 min/day.
* chore: add tsbuildinfo to gitignore
gh pr merge --auto requires branch protection with required status
checks. This repo has no branch protection, so GitHub rejects --auto
with "clean status" error. Remove --auto to merge immediately.
Adds the ability to schedule recurring Docker operations (stack restarts,
fleet snapshots, system prunes) via cron expressions with full execution
history logging. Includes Run Now for on-demand execution.
* feat: add RBAC viewer accounts, atomic deployments, and fleet-wide backups (Pro)
Introduces three Pro-tier features:
- RBAC: Multi-user system with admin/viewer roles, user management UI,
automatic migration from single-admin credentials, viewer restrictions
across the entire UI (read-only editor, hidden action buttons)
- Atomic Deployments: Pre-deploy file backup to .sencho-backup/, automatic
rollback on health probe failure, manual rollback button, health probes
added to stack updates, webhook-triggered deploys use atomic rollback
- Fleet-Wide Backups: Point-in-time snapshots of compose files across all
nodes (local + remote), stored centrally in SQLite, per-stack restore
with optional redeploy, graceful handling of offline nodes
* fix(settings): use correct ProGate prop name in UsersSection
* fix(settings): remove unused isPro prop from UsersSection
* fix(auth): fetch user info after login and setup so isAdmin is set correctly
* feat(pricing): revise pricing strategy and enforce variant-based seat limits
Raise Personal Pro from $49/yr to $69/yr with 3 viewer seats (up from 1).
Add $15/mo billing option for Team Pro. Mark lifetime pricing as a
90-day early-adopter offer. Store Lemon Squeezy variant_name on
activation/validation and enforce seat limits server-side per variant.
* feat(licensing): add Lemon Squeezy checkout, webhook, and billing portal integration
Server-side checkout URL generation (POST /api/checkout) with admin email
pre-fill and instance_id custom data. HMAC-SHA256 verified webhook endpoint
(POST /api/webhooks/lemonsqueezy) handling order, subscription, and payment
lifecycle events for automatic license activation. Customer billing portal
link stored from webhook events and exposed via GET /api/billing/portal.
In-app checkout buttons in Settings with manual license key fallback.
* fix(licensing): exempt Lemon Squeezy webhook from auth middleware
The catch-all auth middleware on /api/* was blocking the public webhook
endpoint. Added /webhooks/lemonsqueezy to the exemption list alongside
/auth/* and /webhooks/:id/trigger.
* feat(pricing): update pricing to final live rates
Personal Pro: $7.99/month, $69.99/year, $249 lifetime.
Team Pro: $49.99/month, $499.99/year, $1,499 lifetime.
Added personal_monthly checkout variant across backend, frontend, and website.
* refactor(licensing): remove server-side checkout/webhook for self-hosted model
Sencho is self-hosted — each user runs their own instance, so there is
no central server to receive webhooks or hold the store API key. Replaced
in-app checkout buttons with a "View Pricing" redirect to sencho.io and
kept manual license key activation as the primary flow.
- Delete LemonSqueezyService (checkout, webhook, HMAC verification)
- Remove POST /api/checkout, GET /api/billing/portal, POST /api/webhooks/lemonsqueezy
- Remove raw body parser and auth exemption for webhook route
- Remove all LEMONSQUEEZY_* env vars from .env.example
- Replace checkout buttons in SettingsModal with single "View Pricing" button
- Simplify LicenseContext checkout to open sencho.io pricing page
- Update licensing docs to reflect website-based purchase flow
* chore: normalize em-dashes to hyphens across codebase (linter)
* chore: remove accidentally tracked directories from index
* chore: add comprehensive .gitignore
* ci: update CI workflow for GitHub Flow
- Change triggers from develop to main (PRs to main + pushes to main)
- Add concurrency controls to cancel stale runs
- Update docker/build-push-action to v6
- Add descriptive job names for branch protection status checks
- Update screenshot refresh and docs sync to trigger on main pushes
* ci: update docker-publish for GitHub Flow
- Remove develop branch trigger (no more dev tag)
- Keep v* tag trigger for releases
- Update docker/build-push-action to v6
* docs: add community and governance files
- CONTRIBUTING.md with dev setup and PR guidelines
- SECURITY.md with vulnerability reporting policy
- CODE_OF_CONDUCT.md (Contributor Covenant v2.1 reference)
- PR template with conventional commits checklist
- Issue templates for bug reports and feature requests
- CODEOWNERS defaulting to @AnsoCode
- Dependabot config for npm (root, backend, frontend) and GitHub Actions
* docs: add README with badges, quick start, and contributing section
* chore: add LICENSE placeholder and open license decision issue (#100)
* docs: update CLAUDE.md for GitHub Flow branching model
- Replace develop-based Git Flow with GitHub Flow (main only)
- All branches now created off main, PRs target main
- Simplify release checklist (no develop-to-main merge step)
- Update testing strategy to reference Vitest and Playwright
- Fix docs.json reference (was mint.json)
* chore: track CLAUDE.md in version control
Remove CLAUDE.md from .gitignore so project workflow instructions
are versioned alongside the code they govern.
* docs: add MANUAL_STEPS.md for GitHub settings that require UI configuration
- Add monaco-editor to frontend deps and configure @monaco-editor/react
to use the local bundle via loader.config({ monaco }) instead of
fetching from cdn.jsdelivr.net (blocked by CSP scriptSrc: self)
- Wire editorWorker via Vite ?worker syntax — blob: URLs already
permitted by existing workerSrc CSP directive, no CSP changes needed
- fix(ci): use DOCS_REPO_TOKEN in release-please so tag creation
cascades to docker-publish.yml (GITHUB_TOKEN cannot trigger workflows)
- fix(ci): auto-merge screenshots PR via gh pr merge --auto --squash
Anso