v1.4.3

Added

• release.yml: pushing a vX.Y.Z tag now publishes a GitHub Release built from the matching CHANGELOG section, gated on the internal ref-lockstep check

Changed

• Fold the standalone release-tag-guard.yml into release.yml as the ref-lockstep gate, so a stale-ref tag never produces a release

Full Changelog: v1.4.2...v1.4.3

v1.4.2

Added

• release-tag-guard.yml: on every v* tag push, fail the tag if the internal _python-react-tests.yml@<ref> pins in the CI/publish workflows don't equal the tag being cut — closes the silent stale-suite footgun behind the v1.4.0/v1.4.1 incident

Changed

• SHA-pin actionlint; add deny-by-default top-level permissions: to codeql.yml and dependabot-auto-merge.yml; drop unused packages: read from the publish release job
• Route the remaining ${{ github.actor }} / ${{ inputs.* }} shell interpolations through env:
• Roll forward action SHAs (dependabot #5): actions/checkout 6.0.3, codeql-action 4.36.1, docker/setup-buildx-action 4.1.0, docker/build-push-action 7.2.0, docker/login-action 4.2.0

Fixed

• Publish refuses to create a release with empty notes when no ## [VERSION] CHANGELOG section exists, and emits a ::warning:: when build-provenance attestation fails instead of shipping silently

v1.4.1

Fixed

• python-react-ci.yml and python-react-publish.yml called the internal
  _python-react-tests.yml building block via a ./ local path. A ./ reference
  inside a reusable workflow that is invoked cross-repo resolves against the
  consumer's repository (which has no such file), not shared-workflows, so every
  consumer pinned at v1.4.0 hit an instant 0-second startup_failure
  (workflow was not found). actionlint does not catch this. Both call sites now use
  the full homelabforge/shared-workflows/.github/workflows/_python-react-tests.yml@v1.4.1
  path. The @ref is self-referential and must be bumped on every future release.

v1.4.0

Changed

• Extracted the shared backend/frontend/e2e/api-freshness matrix into an internal
  _python-react-tests.yml building block that both python-react-ci.yml and
  python-react-publish.yml call — eliminates ~150 lines of duplicated job YAML and
  a real drift it had already caused (the frontend-install dependabot[bot]
  conditional existed in CI but not in publish).
• Publish workflow's docker/release gates simplified to plain needs: — a
  skipped optional job no longer fails the shared tests job, so the previous
  always() && needs.*.result == 'success' guards are no longer required.
• Publish docker now gates on the full shared tests job, which includes E2E.
  Previously docker listed only test-backend/test-frontend/api-types-freshness
  in needs:, so a red E2E did not block the image push; it now does.
• pg-migrations now needs: [tests] (was needs: [test-backend], no longer
  addressable now that the test jobs live inside the reusable suite). Without this it
  ran even when backend lint/type/unit tests had already failed.
• CodeQL: dropped the per-language toolchain setup and dependency-install steps.
  build-mode: none scans source directly and Python dependency installation has
  had no effect on results since CodeQL 2.16 (Jan 2024); build-mode is now wired
  through to the init action. Analysis timeout-minutes lowered from 360 to 45.
• Added explicit timeout-minutes to the frontend, api-freshness, docker-build-test,
  and publish docker/release jobs (previously defaulted to the 6-hour ceiling).
  Backend pytest's inner timeout lowered 25m → 20m so it reports before the job cap.

Migration (required when bumping consumers)

• Status-check context names change. Nesting the test jobs inside the reusable
  tests job renames the four test checks: ci / Backend Tests →
  ci / tests / Backend Tests (likewise Frontend Tests, E2E Tests, API Types
  Freshness). ci / Docker Build Test, ci / PostgreSQL Migration Tests, and the
  codeql / * checks are unchanged.
• Any consumer with branch protection requiring the old names will have PRs stuck on
  "Expected — waiting for status" until the required-status-check contexts are
  updated. Affects the public repos (mygarage, tidewatch, vulnforge, familycircle);
  private free-tier repos have no branch protection and are unaffected.
• Recommended rollout: tag a -rc1, run it on one consumer PR to capture the exact
  new context strings, update branch protection, then bump the rest.

v1.3.1 — Action SHA roll-forward + dogfood auto-merge

Changed

• Roll forward action SHAs merged in PR #2 (codeql-action 4.35.1 → 4.35.4, upload-artifact 7.0.0 → 7.0.1, setup-uv 8.0.0 → 8.1.0) so consumers pinned at v1.3.x pick them up

Added

• .github/workflows/dependabot-auto-merge.yml self-hosted on @main — repo now consumes its own auto-merge workflow so future dependabot PRs merge without manual review
• CHANGELOG.md (this file), backfilled from tag history
• README: collectionsync and myhealth listed as consumers; Per-repo flags table updated to match production; pre-release tag semantics documented in the Publish recipe

v1.3.0 — Node 24 action bumps + dependabot enabled

What changed

Bumps the 5 remaining node20-runtime actions to node24 majors:

Action	Was	Now
docker/build-push-action	v6	v7.1.0
docker/login-action	v3	v4.1.0
docker/setup-buildx-action	v3	v4.0.0
softprops/action-gh-release	v2	v3.0.0
dependabot/fetch-metadata	v2.4.0	v3.1.0

All five major bumps are runtime-only — no API breaks. Verified each pinned SHA exposes using: node24 in its action.yml.

Adds .github/dependabot.yml so future action bumps land via auto-PR (this repo previously had no dependabot — explains why the node20 pins survived).

Why now

• 2026-06-02 — Node 24 becomes the runner default; node20-pinned actions get force-bumped (mostly transparent).
• 2026-09-16 — Node 20 removed from runners; runs.using: node20 actions hard-fail.

Consumer migration

Update your uses: reference to @v1.3.0:

uses: homelabforge/shared-workflows/.github/workflows/python-react-publish.yml@v1.3.0

Affected repos: mygarage, tidewatch, vulnforge, familycircle, myhealth.

Bonus fix

Pre-existing actionlint failure on main (SC2034 in pg-migrations wait loop, introduced in v1.2.0) is also resolved.

🤖 Generated with Claude Code

v1.2.0 — pg-migrations job (opt-in)

What's new

New optional `pg-migrations` job in `python-react-ci.yml` that exercises the consumer's `docker-compose.test.yml` stack and runs `pytest tests/migrations/` against a real PostgreSQL sidecar.

Off by default, so this is non-breaking for consumers that bump to v1.2.0 without enabling it.

Why

mygarage v2.27.0-rc1 shipped migration 054 with two PG-only SQL bugs (`DATETIME` column type, `ADD CONSTRAINT IF NOT EXISTS`) that all CI runs ignored — the SQLite path is typeless and the existing PG path always called `Base.metadata.create_all` first, so the migration's literal SQL never executed against PG.

This job changes that: load a pre-migration `pg_dump` baseline into a clean PG schema, run the migration under test, assert the post-state on real PG.

Adoption

• mygarage: opts in as part of v2.27.0-rc2.
• familycircle, tidewatch, vulnforge, collectionsync: bump to `@v1.2.0` for the version-pin sync; opt in once you ship a `docker-compose.test.yml` and `backend/Dockerfile.test`.

Inputs (all optional, defaults match the mygarage pattern)

```yaml
enable-pg-migrations: true # gate, default false
pg-migrations-compose-file: docker-compose.test.yml
pg-migrations-service: mygarage-test
pg-migrations-pytest-path: tests/migrations/
```

Reference

• mygarage rc2 plan: ${HOME}/.claude/plans (private) — Phase 4.5
• Implementation: `.github/workflows/python-react-ci.yml` lines added under `pg-migrations:`

v1.1.3

Fixed

• Publish workflow's release job needs an explicit always() guard for its if: expression to evaluate at all

v1.1.2

Fixed

• Publish workflow gates the release job explicitly on docker.result == 'success'

v1.1.1

Fixed

• Publish workflow allows the docker job to proceed when api-types-freshness is skipped (was previously blocked by the conditional-need evaluation)