Most of docker.yaml was doing work that was duplicated or hazardous now
that releases are cut from a tag.
The tests were duplicated exactly: release.yaml and docker.yaml called
the same reusable tests.yaml, on the same commit — once before drafting,
again after publishing. No new information, and the image build queued
behind it. Pint likewise: check.yaml already style-checked the commit
when it landed. Both jobs go; coverage is unchanged.
manual_docker_build goes too, and it was worse than redundant. Its
checkout took no ref, so it built the dispatched branch while tagging
with whatever string was typed — an image could be labelled 2.4.2 while
containing 2.x HEAD — and `tag` defaulted to "latest", so a careless
dispatch republished the moving stable tag from a branch. #710 had to add
a guard purely to stop the registration dispatch doing that by accident.
It was last used in September 2025 to push the legacy and alpha tags
during the Docker distribution work; that is finished, and releases
produce images now. A patched base image is better served by a patch
release than by silently changing what a pinned tag contains.
That cascade removes the tag input and the #710 guard as well, leaving
register_tag as the only dispatch input and two jobs in the file.
Losing the test gate would leave the image build ungated, so the release
build now refuses a release with no InvoiceShelf.zip. A release either
came from the tested pipeline or it gets no images — the updater is
already protected this way, since registration downloads that same asset.
GitHub offers no way to forbid hand-made releases; this is the closest
thing, which is to make them inert.
"Docker" no longer describes a workflow that registers on the updater and
publishes images, so it becomes publish.yaml — matching its trigger and
pairing with release.yaml, which prepares what this distributes. The
recovery instructions in AGENTS.md name this workflow and would have
broken silently, so they move with it.
2.4.3-beta.2 was cut by tag and came out correctly — published,
pre-release, zip attached, notes from CHANGELOG.md — and then nothing
else happened. No updater registration, no Docker images.
GitHub does not start workflow runs from events created with
GITHUB_TOKEN. The publish step authenticated as github-actions[bot], so
`release: published` fired and triggered nothing. Every earlier
docker.yaml run was event=release from a release a human published,
which is why beta.1 worked and beta.2 did not. 3.x carries the same
design and would have failed identically on the first RC.
The workflow now stops at the draft. Everything else is unchanged: the
tag still runs the tests, reads the notes, builds the package and
attaches it. Pressing Publish fires the event under a real identity and
the proven downstream runs as it always has — and it puts a deliberate
gate in front of a release going public.
prerelease and make_latest move onto the draft rather than being applied
at publish time, so the flags are already right when the button is
pressed; GitHub's publish dialog otherwise defaults "Set as the latest
release" to checked, which would let a 3.0.0 alpha displace 2.4.x.
The run now ends by writing the draft URL and the resolved flags to the
job summary, since a draft nobody knows about is no use.
Documents the whole flow in AGENTS.md, including why publishing is
manual — the reasoning is not guessable from the workflow alone.
The CHANGELOG.md section was read after composer, pnpm and the frontend
build had all run, so tagging without notes spent a full build before
failing on something knowable in the first seconds. It only needs PHP, so
it now runs directly after the PHP setup.
Noticed while dry-running a tag with no section against #715: the run
correctly refused to publish, but took a whole build to say so.
release.yaml has never run. It listens for "v*" tags while every tag ever
cut is bare — 3.0.0-alpha.1, 2.4.2, 2.4.3-beta.1 — so tagging by the
established convention produced silence, and whoever cuts 3.0.0 would
have hit that first. It now accepts both spellings.
It also hand-copied the release file list, which docker.yaml then rebuilt
via `make clean dist` and uploaded with overwrite: true. The two lists
were identical, so nothing had broken yet, but which zip users received
was decided by job ordering. `make dist` owns the artifact now and the
duplicate is gone.
The release is created as a draft with the package already attached and
published in a separate step, so `release: published` fires only once the
tests have passed and the asset is in place. A failed run leaves no
release at all, rather than a published one nobody can download — which
is what 2.4.2 left behind. Registration can no longer race the upload
either, so docker.yaml drops its build job, and register_release loses
both that dependency and the always() dance it needed to survive the job
being skipped on a manual dispatch.
GitHub's "Latest release" pointer is gated on LATEST_MAJOR, exactly as
docker.yaml gates its moving image tags: a 3.0.0 alpha can no longer
displace 2.4.x as the release users are shown first. Release notes come
from CHANGELOG.md instead of being generated from commits, matching where
the updater already reads them, and a tag with no section fails before
anything is published.
The test job moves to a reusable workflow rather than being written out
in both places — the duplicated file list above is the argument.
* build: migrate frontend tooling to pnpm (v3)
Rebuilds the stale #673 on current 3.x so it doesn't revert #657's test
split, the Node-24 action bumps, or composer-install@4.0.0.
- package.json: packageManager pnpm@11.6.0; drop dead 'resolutions'
- pnpm-workspace.yaml: nodeLinker hoisted, allowBuilds vue-demi,
overrides brace-expansion (replaces resolutions)
- pnpm-lock.yaml generated via 'pnpm import' from yarn.lock (keeps the
resolved versions, incl. vite 8.0.3 / rolldown rc.12); yarn.lock removed
- docker.yaml + release.yaml: pnpm/action-setup@v6 + cache pnpm + pnpm
install/build (action versions and the #657 split left intact; check.yaml
needs no change — its test job is PHP-only after #657)
- 3 Dockerfiles: node:24 + corepack + pnpm install --frozen-lockfile && pnpm build
- Makefile, composer 'dev' script, CLAUDE.md, .gitignore -> pnpm
* fix(deps): pin vite to 8.0.5 (security)
Now that 3.x is the default branch, Dependabot flags vite <8.0.5. Pin to
8.0.5 (the patched version), which keeps rolldown 1.0.0-rc.12 — still
below 8.0.15 where the broken rolldown 1.0.3 (the init_runtime_dom_esm_bundler
chunk regression) starts, so the build stays clean. Mirrors v2's #674.
* ci: speed up the test job (disable Xdebug, drop frontend build, run parallel)
The `tests` job in check.yaml carried three sources of wasted wall-clock,
none of which it actually used:
- `coverage: xdebug` loaded Xdebug into every PHP process, but no step ever
passes `--coverage` — so it was pure tax (~2-3x slower execution). Switch
to `coverage: none`. If coverage is wanted later, use pcov + `--coverage`.
- The job ran `npm install` + `npm run build` before the PHP tests. The
feature suite is API/JSON only (49/56 feature files use getJson/assertJson)
and nothing renders the Vite blade, so the built assets are never needed.
Drop the Node/Vite steps; release & docker workflows still build assets.
- Tests ran single-process. brianium/paratest is already installed and the
runner has 4 cores, so run `php artisan test --parallel`.
Validated locally: full suite passes in parallel (exit 0), including
repeated runs of the two filesystem-writing module tests — no races.
docker.yaml carries the same pattern but only runs on release/nightly cron,
so it is left for a follow-up.
* ci: apply the same test-job speedups to docker.yaml
The release/nightly `tests` job in docker.yaml carried the identical waste
that check.yaml had: Xdebug loaded but never used for coverage, an
unnecessary frontend build before the PHP tests, and serial execution.
Mirror the check.yaml fix: coverage: none, drop the Node/Vite steps
(the suite is API/JSON and the separate release_artifact_build job builds
its own assets), and run php artisan test --parallel.
* ci: run module-scaffolding tests serially under --parallel
The Modules/* tests (module:make ScaffoldProbe + modules_statuses.json
toggles) mutate shared on-disk module state. paratest isolates the DB
per worker but NOT the filesystem, so concurrent workers boot with
ScaffoldProbe enabled and fatal on the un-autoloaded ServiceProvider
(31 failures). Tag them 'modules' (Pest group on Feature/Company/Modules)
and split CI: parallel --exclude-group=modules, then serial --group=modules.
* ci: stub Vite in tests + bump all actions to Node 24 versions
Part A (fixes#657): the customer-portal entrypoint test renders the SPA
shell (app.blade.php → @vite). With the frontend build dropped from CI
there's no manifest, so it 500'd (ViteManifestNotFoundException). Call
$this->withoutVite() in TestCase::setUp() so SPA-shell renders work
without a built manifest; the build stays dropped.
Part B: bump every Node-20 action to its node24 release — checkout v4->v6,
setup-node v4->v6, paths-filter v3->v4, cancel-workflow-action 0.12.1->0.13.1,
softprops/action-gh-release v2->v3, docker/{setup-buildx v3->v4, login v3->v4,
metadata v5->v6, build-push v5->v7}. setup-php@v2, ramsey/composer-install@v2
(composite) and svenstaro/upload-release-action@v2 are already node24.
* ci: bump ramsey/composer-install v2 -> 4.0.0 (node24 internal cache)
composer-install@v2 is composite but internally calls actions/cache@v3
(Node 20), which still trips the deprecation. 4.0.0 uses actions/cache
v5.0.3 (Node 24) and keeps the composer-options input we use.
- Add manifest.json generation script (scripts/generate-manifest.php)
- Add Updater::cleanStaleFiles() that removes files not in manifest
- Add /api/v1/update/clean endpoint with backward compatibility
- Add configurable update_protected_paths in config/invoiceshelf.php
- Update frontend to use clean step instead of delete step
- Add GitHub Actions release workflow triggered on version tags
- Add .github/release.yml for auto-generated changelog categories
- Update Makefile to include manifest generation and scripts directory
