Repository navigation
Forge CI: ci, release and deploy-website workflows (.ultimator/) - #108
Conversation
…ted from GitHub's Linux jobs in sandboxes with Nix (./.ultimator/actions/nix), packages also on arm64-ci and crab, Windows x86_64 on crab-win under emulation (./.ultimator/actions/windows-x64); the reusable workflows become composite actions. The release verifies the tag's SSH signature against vars.YAS_TAG_SIGNERS, keeps a release-<tag> artifact with SHA256SUMS, and publishes with CARGO_REGISTRY_TOKEN and NPM_TOKEN. GitHub's workflows stay until Forge's P4.
…RS (Forge has no repository variables yet)
There was a problem hiding this comment.
Ultimator's review of 09d389b
Adds Forge CI workflows under .ultimator/ (ci, release, deploy-website) and three composite actions (nix, packages, windows-x64), ported from the existing GitHub workflows. I found no defects in the diff itself. The x86_64 PE-machine check (6486), job dependencies, secret scoping and artifact names are consistent. I couldn't run the workflows or read the scripts they call (bin/coverage, bin/publish-npm-packages and similar), and the PR says the workflows haven't run yet.
No issues found.
Reviewed in 43s · Session · @ultimator-agent review reviews again · @ultimator-agent fix fixes the open issues
There was a problem hiding this comment.
Ultimator's review of 09d389b
The new commit only changes where the tag signers come from: the YAS_TAG_SIGNERS secret instead of a repository variable. The secrets. reference, error message, header comment and PR description all agree. Nothing new to report.
No issues found.
Reviewed in 9s · Session · @ultimator-agent review reviews again · @ultimator-agent fix fixes the open issues
There was a problem hiding this comment.
Ultimator's review of 6957cd5
The new commit only reformats the release job's needs list across lines. The list is the same eight jobs, so behavior is unchanged. Nothing new to report.
No issues found.
Reviewed in 8s · Session · @ultimator-agent review reviews again · @ultimator-agent fix fixes the open issues
Coverage
|
Forge P3 (design m5weenadk7pdbxgx §10). This adds YAS's workflows in Forge's CI format. The GitHub workflows stay as they are and keep running until Forge's P4.
What it adds (
.ultimator/)actions/nixReplaces
DeterminateSystems/nix-installer-actionandmagic-nix-cache-action, which are Marketplace actions Forge doesn't run.actions/packagesandactions/windows-x64GitHub's reusable
_build-packages.ymland_build-windows.ymlbecome composite actions: Forge has no reusable workflows.Windows x86_64 builds on crab-win (Windows 11 ARM64) under x64 emulation:
stable-x86_64-pc-windows-msvctoolchain (--force-non-host) and checks thatyas.exe's PE machine is x86_64.workflows/ci.ymlThe same jobs as GitHub's:
sandbox(linux-x86_64),arm64-ci(linux-aarch64) andcrab(macos-aarch64, with the macOS graph tests);crab-win.workflows/release.ymlOn
v*tags.git verify-tagagainstYAS_TAG_SIGNERS, an allowed_signers line. That replaces GitHub's "verified identity" check. Without it, or for an unsigned tag, the release stops.YAS_TAG_SIGNERSis a sealed secret only because Forge has no repository variables yet, and admins alone set secrets.release-<tag>with the stable asset names andSHA256SUMS, kept 400 days. P4 gives releases a home on Forge.CARGO_REGISTRY_TOKEN;NPM_TOKEN, written to the job's npmrc.--provenanceis dropped: it needs GitHub's OIDC.workflows/deploy-website.ymlnix run .#deploy-websitewithFLY_API_TOKEN, on the same paths as GitHub's workflow.Evidence
ultimator ci check .ultimator, built from xmit-dev/ultimatorforge/p3-store, reads and plans every file with no errors:ci.yml: 11 jobs;release.yml: 17 jobs;deploy-website.yml: 1 job;The jobs run on
sandbox,arm64-ci,crabandcrab-win.Not run yet. That needs Pierre's steps:
cimodule on;refs/tags/v*:CARGO_REGISTRY_TOKEN,NPM_TOKENandYAS_TAG_SIGNERS;main:FLY_API_TOKEN;mainandrefs/tags/v*, so those runs are trusted.