Jon Chery
03adaa80a6
Byte-identical .github/workflows/publish.yml + mirror on the dev forge
(<dev-forge>/workflows/publish.yml) — same file content, installed in
both locations per the repo's byte-identical workflow convention.
NFR-6 (wheel/layer co-versioning): on push to main affecting core/**,
adapters/**, nova/**, or pyproject.toml, the workflow publishes BOTH a
wheel AND a Lambda layer with identical version strings. If either
publish fails, the job fails and the merge is blocked (REQ-323 AC).
Steps:
- actions/checkout@v4 + actions/setup-python@v5 (python 3.12)
- aws-actions/configure-aws-credentials@v4 (OIDC, role-to-assume from
AWS_ROLE_ARN secret, id-token: write)
- pip install build twine
- compute version: tomllib.load(pyproject.toml)["project"]["version"]
→ steps.ver.outputs.version (e.g. 1.14.0)
- python -m build --wheel
- twine upload dist/nova-<ver>-*.whl with two modes:
* CodeArtifact: NOVA_CODEARTIFACT_DOMAIN set →
aws codeartifact login --tool twine --domain $DOMAIN --repository
nova-pypi
* Fallback: NOVA_CODEARTIFACT_DOMAIN unset → TWINE_REPOSITORY_URL +
TWINE_USERNAME + TWINE_PASSWORD secrets (any PEP 503 index)
Idempotent: a re-upload that hits "file already exists" is treated as
success.
- build Lambda layer: pip install --target layer/python/ the wheel +
argon2-cffi + cryptography + pyjwt, then zip -r nova-layer.zip python/
- aws lambda publish-layer-version --layer-name nova-cli
--compatible-runtimes python3.12 --compatible-architectures x86_64
--description "nova-cli v<ver>" → steps.layer.outputs.arn
- aws ssm put-parameter /nova/layer/nova-cli/version =
"<wheel-version>:<layer-arn>" (CAP-035)
- final guard step fails the job if wheel uploaded!=true or layer arn
is empty
permissions: id-token: write (OIDC), contents: write (tag).
Secrets documented in the workflow header comments.
---ci---
project: acdl
phase: 1
milestone: v1.28
status: execute
persona: backend-engineer
---/ci---
Gitea Workflows — Limitation Documentation (v1.14, REQ-150)
Shared workflows (byte-identical Gitea + GitHub)
These 3 workflows exist in both .gitea/workflows/ and .github/workflows/
and are byte-identical (asserted by tests/test_pipeline_contract.py):
ci.yml— lint + test + check-only (runs on every PR)deploy.yml— reusable deploy workflow (invoked by consumer repos)modules-lifecycle.yml— L1 + L2 module lifecycle pipeline (plan-only default, full on workflow_dispatch override)
GitHub-only workflows (no Gitea mirror)
These 4 workflows exist only in .github/workflows/:
platform-test.yml— PR pipeline: lint + unit + integration + schema validation. Uses GitHub Actions features (reusable workflow composition, environment protection) not available in Gitea Actions.primitives-plan.yml— PR plan-only matrix over all L1 primitives. Uses GitHub matrix strategy +terraform planagainst live AWS.patterns-plan.yml— PR plan-only matrix over all L2 modules. Same pattern as primitives-plan.release.yml— release job on merge to main: computes next semver, creates + updates MAJOR.MINOR.PATCH / MAJOR.MINOR / MAJOR floating tags, creates a GitHub release. GitHub-only by design (Gitea releases are created via the ship workflow's API call, not a workflow).
Why no Gitea mirror
Gitea Actions (act_runner) has limited support for reusable workflow
composition, environment protection, and the gh CLI used by the release
job. The 3 shared workflows are the ones that need to run on both forges
(CI + deploy + lifecycle). The 4 GitHub-only workflows are the
production-grade platform pipelines that run on GitHub Actions; Gitea is
the dev/integration forge. Mirroring them would require feature parity
that Gitea Actions does not currently provide.
This is a documented limitation, not a defect. A future milestone may add Gitea mirrors if act_runner gains the required features.