Repository navigation
fix(sites): make ci init workflows deploy and install correctly - #246
jamie-at-bunny wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: 7705c8d The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7705c8df9c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const candidates = | ||
| projectRoot === root || rootIsWorkspace | ||
| ? [projectRoot, root] | ||
| : [projectRoot]; | ||
| const lockDir = candidates.find((dir) => | ||
| LOCKFILES.some((name) => existsSync(join(dir, name))), |
There was a problem hiding this comment.
Run npm installs where the root lockfile is usable
For a nested npm workspace whose only package-lock.json is at the repository root, this selects the root as lockDir and marks the install as frozen, but the generated job applies defaults.run.working-directory to the child project and emits npm ci there. npm ci does not walk up to the workspace-root lockfile; with npm 11.4.2 it exits with “can only install with an existing package-lock.json” when invoked from such a child. Consequently the newly advertised monorepo workflow fails before building, so the install step must run from lockDir/the repository root or the root lockfile must not be treated as usable from the child.
Useful? React with 👍 / 👎.
| const packageManager = await detectPackageManager(lockDir ?? projectRoot); | ||
| return { | ||
| packageManager, | ||
| lockfile: lockDir !== undefined, | ||
| pnpmVersion: | ||
| packageManager === "pnpm" | ||
| ? await pnpmVersion(root, projectRoot, lockDir) |
There was a problem hiding this comment.
Honor packageManager when no lockfile exists
When lockDir is absent, detectPackageManager(projectRoot) only inspects lockfile names and therefore always falls back to npm, even if package.json declares "packageManager": "pnpm@10" or the repository contains pnpm-workspace.yaml. The generated lockfile-less workflow then emits npm install and npm run build; pnpm/Yarn-specific workspaces or dependency protocols can fail even though this change claims to support lockfile-less projects. Use the package-manager field or workspace marker before falling back to npm.
Useful? React with 👍 / 👎.
| export async function defaultBranch(root: string): Promise<string> { | ||
| const ref = await runGit(root, [ | ||
| "symbolic-ref", | ||
| "--short", | ||
| "refs/remotes/origin/HEAD", | ||
| ]); | ||
| return ref?.replace(/^origin\//, "") || "main"; |
There was a problem hiding this comment.
Refresh the remote default branch before embedding it
refs/remotes/origin/HEAD is only a locally cached symbolic ref, not necessarily the remote's current default branch. I reproduced with Git 2.43.0 that after changing a bare remote from master to main and fetching normally, this command still returns origin/master; Git exposes git remote set-head <name> --auto as a separate operation. Running sites ci init from such a common post-rename clone therefore generates a workflow that listens to the obsolete branch, so pushes to the documented default branch never deploy; resolve the remote HEAD or refresh the cached symref first.
AGENTS.md reference: AGENTS.md:L3-L5
Useful? React with 👍 / 👎.
|
| export async function defaultBranch(root: string): Promise<string> { | ||
| const ref = await runGit(root, [ | ||
| "symbolic-ref", | ||
| "--short", | ||
| "refs/remotes/origin/HEAD", | ||
| ]); | ||
| return ref?.replace(/^origin\//, "") || "main"; |
There was a problem hiding this comment.
Default-branch pushes can be missed
If origin/HEAD is missing after git init and a push, or stale after GitHub's default branch changes, defaultBranch selects main or the old branch. The generated workflow then ignores pushes to the actual default branch, so they never deploy. Query the remote's current default branch before falling back.
| const packageManager = await detectPackageManager(lockDir ?? projectRoot); | ||
| return { | ||
| packageManager, | ||
| lockfile: lockDir !== undefined, | ||
| pnpmVersion: | ||
| packageManager === "pnpm" | ||
| ? await pnpmVersion(root, projectRoot, lockDir) |
There was a problem hiding this comment.
pnpm projects install with npm
The lockfile-free path still chooses npm for pnpm projects. detectPackageManager ignores packageManager and pnpm-workspace.yaml, so even a project pinned to pnpm gets npm install. If the workspace uses workspace:* dependencies, npm rejects them and deployment stops at installation. Without a lockfile, use the project's manager pin or workspace configuration before defaulting to npm.
Knowledge Base Used: Framework detection
| ...(opts.cliVersion | ||
| ? [` cli_version: ${JSON.stringify(opts.cliVersion)}`] | ||
| : []), |
There was a problem hiding this comment.
CLI version output lacks tests
No test covers the new cli_version output. Existing deploy assertions call renderSitesWorkflow without cliVersion, so deleting this output would leave them passing while generated deployments stopped selecting the CLI's minor line. Add tests for a supplied value and for omission when no value is supplied.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
This review was skipped because it would exceed your organization's monthly flex usage limit. Raise the limit in billing settings or wait until the next billing period resets limits.
Fixes
bunny sites ci initworkflows so they deploy and install correctly.