Skip to content

fix(sites): make ci init workflows deploy and install correctly - #246

Open
jamie-at-bunny wants to merge 2 commits into
mainfrom
sites-ci
Open

jamie-at-bunny wants to merge 2 commits into
mainfrom
sites-ci

Conversation

@jamie-at-bunny

Copy link
Copy Markdown
Member

Fixes bunny sites ci init workflows so they deploy and install correctly.

@changeset-bot

changeset-bot Bot commented Oct 7, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 7705c8d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages
Name Type
@bunny.net/cli Patch
@bunny.net/framework-detector Patch
@bunny.net/cli-darwin-arm64 Patch
@bunny.net/cli-darwin-x64 Patch
@bunny.net/cli-linux-arm64 Patch
@bunny.net/cli-linux-x64 Patch
@bunny.net/cli-windows-x64 Patch

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

@bunnynet-devops

Copy link
Copy Markdown

@codex review

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-07T16:27:35.538559Z 7705c8d Manual request
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment on lines +93 to +98
const candidates =
projectRoot === root || rootIsWorkspace
? [projectRoot, root]
: [projectRoot];
const lockDir = candidates.find((dir) =>
LOCKFILES.some((name) => existsSync(join(dir, name))),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +100 to +106
const packageManager = await detectPackageManager(lockDir ?? projectRoot);
return {
packageManager,
lockfile: lockDir !== undefined,
pnpmVersion:
packageManager === "pnpm"
? await pnpmVersion(root, projectRoot, lockDir)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +29 to +35
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";

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@greptile-apps

greptile-apps Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

RetriggerConfidence Score: 3/5

[Medium risk] Fixes CI workflow generation for sites deployment.

Fix branch lookup and lockfile-free pnpm selection before merging; both can leave generated workflows unable to deploy.

Fix All in Claude CodeFindings

  1. P1 Default-branch pushes can be missed ▶
  2. P1 pnpm projects install with npm ▶
  3. P2 CLI version output lacks tests ▶

Summary

Updates generated Sites workflows to use deploy-site 0.1.1 and the CLI's minor version, select a branch from origin/HEAD, and improve dependency installation.

  • Adds root-lockfile lookup for workspaces, explicit pnpm versions, and uncached installs without lockfiles.
  • Adds Python generator installs when requirements.txt is absent.
  • Default-branch lookup and lockfile-free pnpm selection still leave deployment paths broken.
  • The new cli_version input needs regression coverage.
Diagram
%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Site configuration and project files] --> B[Choose framework and install settings]
  C[Local origin HEAD] --> D[Choose deployment branch]
  B --> E[Render GitHub workflow]
  D --> E
  V[CLI minor version] --> E
  E --> F[Install dependencies and build]
  F --> G[Deploy through deploy-site 0.1.1]
Loading

Reviews (1) · Last reviewed commit: "fix(sites): make ci init workflows deplo..." · Reviewed by Greptile

Comment on lines +29 to +35
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";

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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.

Fix in Claude Code

Comment on lines +100 to +106
const packageManager = await detectPackageManager(lockDir ?? projectRoot);
return {
packageManager,
lockfile: lockDir !== undefined,
pnpmVersion:
packageManager === "pnpm"
? await pnpmVersion(root, projectRoot, lockDir)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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

Fix in Claude Code

Comment on lines +227 to +229
...(opts.cliVersion
? [` cli_version: ${JSON.stringify(opts.cliVersion)}`]
: []),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 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!

Fix in Claude Code

@greptile-apps greptile-apps Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.

3 participants