The multiline body content from CHANGELOG.md will not be properly passed to the GitHub API with this approach. When using BODY=$(cat /tmp/release-notes.txt) followed by -f body="$BODY", the shell will expand the variable with newlines, but gh api -f expects a string parameter and may not handle embedded newlines correctly.

The previous approach using --notes-file /tmp/release-notes.txt with gh release create properly handled multiline content by reading from a file. With the direct API call, you should use the @ syntax to read from a file: -F body=@/tmp/release-notes.txt instead of -f body="$BODY".

Note the difference:

• -f (lowercase) sends data as form fields and expects string values
• -F (uppercase) can read from files when prefixed with @

This will ensure the changelog content is correctly sent as the release body.

The workflow doesn't handle the scenario where a release already exists for the tag. According to the GitHub API documentation, POSTing to /repos/{owner}/{repo}/releases with a tag_name that already has a release will result in a 422 error.

While this is better than silently creating an untagged-* draft (which was the old behavior), the workflow will fail without a clear error message. Consider adding error handling or checking if a release already exists before attempting to create one.

One approach could be to add a check before the API call:

if gh release view "$TAG_NAME" >/dev/null 2>&1; then
  echo "Release for $TAG_NAME already exists"
  gh release view "$TAG_NAME" --json htmlUrl --jq '.htmlUrl'
else
  # create the release
fi

This would make the workflow more robust and provide clearer feedback when a release already exists.

Line 36 captures the changelog content into the BODY variable, but this variable is no longer needed if the fix for multiline content handling is applied (using -F body=@/tmp/release-notes.txt instead of -f body="$BODY"). This line can be removed to simplify the script.

API POST fails with 422 when release already exists

High Severity

The PR description identifies that "something creates a GitHub release for the tag ~60 seconds before the publish-cli workflow starts." The GitHub REST API POST /repos/{owner}/{repo}/releases returns a 422 Validation Failed (already_exists) error when a release for that tag_name already exists. This means the create-release job will fail, and since build-and-publish has needs: [create-release], the entire binary upload pipeline stops — no binaries get built or uploaded at all. This is a regression from the old behavior, where gh release create at least allowed the pipeline to continue (producing an untagged-* draft).

Shell variable for body less robust than file input

Low Severity

Capturing release notes via BODY=$(cat /tmp/release-notes.txt) and passing them with -f body="$BODY" introduces unnecessary fragility — command substitution strips trailing newlines and passes potentially large content through a shell variable. The gh api command natively supports reading file content via -F body=@/tmp/release-notes.txt, which is more robust, eliminates the intermediate BODY variable, and is the idiomatic approach.