Activate @heddleagent/run-client - #347
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 109ba49937
ℹ️ 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".
| '--cache', | ||
| npmCache, | ||
| ], repositoryRoot); | ||
| const packResult = JSON.parse(packed.stdout)[0]; |
There was a problem hiding this comment.
In the inspected publish-packages.yml run-client job, npm is pinned to 12.0.2 before this verifier runs. With npm 12, npm pack --json returns an object keyed by package name rather than the npm 10 array shape; the repository already handles this in scripts/execution-host-client-pack-result.mjs:1-20. Indexing that object with [0] makes packResult undefined, so the following assertions fail and block the initial run-client publication. Parse the result with the existing npm-version-compatible helper.
Useful? React with 👍 / 👎.
| const publishedVersion = JSON.parse(result.stdout); | ||
| if (publishedVersion !== packageJson.version) { |
There was a problem hiding this comment.
When @heddleagent/run-client@6.0.0 is already published, the pinned npm 12 release job returns the single npm view --json result in an array, as accounted for by parseNpmViewResult in scripts/execution-host-client-release-state.mjs:74-95. Comparing that array directly with the version string always reports a mismatch, so every later release-workflow run stops at “Select release state” instead of recognizing the existing artifact.
Useful? React with 👍 / 👎.
| if gh release view "${RELEASE_TAG}" >/dev/null 2>&1; then | ||
| test "$(gh release view "${RELEASE_TAG}" --json targetCommitish --jq .targetCommitish)" = "${GITHUB_SHA}" |
There was a problem hiding this comment.
After the first release, any later invocation of publish-packages.yml still runs this job, including pushes triggered by another package or yarn.lock. The existing run-client-v6.0.0 release necessarily targets its original commit rather than the new GITHUB_SHA, so this equality test makes the workflow fail on every subsequent relevant push. The inspected gh release view --help confirms targetCommitish is the field being queried; gate finalization on a newly selected release or verify the immutable tag against its original commit, as the other package lanes do.
Useful? React with 👍 / 👎.
1 participant
Summary
Verification