Skip to content

ci: move the codefly pin to 0.1.180 so CI reads the migrated declarations (Refs #952) - #1035

Closed
antoinetoussaint-byte wants to merge 1 commit into
mainfrom
pin-codefly-180
Closed

antoinetoussaint-byte wants to merge 1 commit into
mainfrom
pin-codefly-180

Conversation

@antoinetoussaint-byte

@antoinetoussaint-byte antoinetoussaint-byte commented Oct 7, 2026 •

Copy link
Copy Markdown
Contributor

#953 migrated every endpoint declaration to the reach/addressing split core v0.14.0 introduced. The CI pin was still 0.1.171, which vendors a core that refuses the new spelling — so the declarations on main and the CLI that reads them disagree, and nothing can be released until they agree.

Why this is its own PR and not part of #953. codefly ci plan --base <main> loads the base revision's workspace with the head's CLI. A single PR carrying both the declarations and the pin can therefore never be green: the new CLI reads the old declarations from the base. The order is forced — declarations first against the old pin, then the pin alone.

Why a fresh branch rather than rebasing #1031. That branch predates #953 and carries 440 files; rebasing it onto the merged declarations replays work already on main and conflicts immediately. This takes only scripts/ci/install-codefly.sh, which is the whole of the change. #1031 should be closed in favour of this.

Next: a release carrying the migrated declarations, which is the last pin a composing platform workspace needs before its deployment render stops refusing.

… v0.14.0 (Refs #952)

#953 migrated every endpoint declaration to the reach/addressing split core
v0.14.0 introduced. The pin was 0.1.179, whose CLI vendors core v0.8.1 —
checked at the tag, not inferred — so it predates the split entirely and
reads none of the new spelling. 0.1.180 is the first release vendoring
v0.14.0.

The installer's default and ci-performance.test.mjs's DEFAULT_CODEFLY_VERSION
move together, because that test exists to keep the two in sync: a pin moved
in one place and not the other is the failure it was written to catch, and it
caught this.

Pin-only, and deliberately a fresh branch rather than a rebase of the earlier
one: that branch predated #953 and carried 440 files, so rebasing it onto the
merged declarations would have replayed work already on main.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@antoinetoussaint-byte

Copy link
Copy Markdown
Contributor Author

Closing in favour of #1031, which the saas-starter session owns and has verified locally.

I opened this without checking what that session already had in flight, which was my mistake: it had both the pin rebuild and the release commit (#1037) prepared. Two pin PRs against one repo is exactly the duplication the one-objective-one-PR rule exists to prevent.

For the record, this branch was also failing for a real reason worth keeping: at the 0.1.180 pin, codefly ci run refuses marketing/http during the agent's runtime-init — GenerateNetworkMappings: endpoint marketing/http declares visibility "public" but states no exposure — even though that service's manifest on main does declare exposure: public, and both a local 0.1.180 build and a core v0.15.0 build generate its mapping without complaint from the workspace on disk. So the endpoint CI validates is not the one in the manifest. Whoever lands the pin should know that before re-running it.

auto-merge was automatically disabled October 7, 2026 19:43

Pull request was closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant