Fix integration-batch workflow outputs by compacting JSON before writing to $GITHUB_OUTPUT

[Copilot]

integration-batch failed in dry-run because multi-line JSON was written to $GITHUB_OUTPUT, which GitHub Actions rejects (Invalid format ' {'). This change normalizes workflow JSON outputs to single-line/compact form to preserve existing behavior while making output commands valid.

• Workflow output formatting (.github/workflows/integration-batch.yml)

  • Compacted prs_json in Compute candidate PR list before writing to $GITHUB_OUTPUT.
  • Compacted selected and skipped in Filter to PRs with successful combined status.
  • Compacted merged and merge_skipped in Merge selected PRs.

• Behavioral scope

  • No selection, merge, labeling, PR update, or summary logic changes.
  • Job summary robustness remains as-is; this PR only fixes output serialization format.

# Before (can be multi-line JSON -> invalid for $GITHUB_OUTPUT)
echo "selected=$selected" >> "$GITHUB_OUTPUT"

# After (single-line JSON)
echo "selected=$(echo "$selected" | jq -c .)" >> "$GITHUB_OUTPUT"

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/rockcarver/frodo-cli/releases
  • Triggering command: /opt/hostedtoolcache/node/24.14.1/x64/bin/node /opt/hostedtoolcache/node/24.14.1/x64/bin/node --no-warnings --enable-source-maps --experimental-loader file:///home/REDACTED/work/frodo-cli/frodo-cli/dist/loader.cjs /home/REDACTED/work/frodo-cli/frodo-cli/dist/app.cjs shell in/node committer.name (http block)
  • Triggering command: /opt/hostedtoolcache/node/24.14.1/x64/bin/node /opt/hostedtoolcache/node/24.14.1/x64/bin/node --no-warnings --enable-source-maps --experimental-loader file:///home/REDACTED/work/frodo-cli/frodo-cli/dist/loader.cjs /home/REDACTED/work/frodo-cli/frodo-cli/dist/app.cjs shell o-cli/node_modules/.bin/watchman (http block)
  • Triggering command: /opt/hostedtoolcache/node/24.14.1/x64/bin/node /opt/hostedtoolcache/node/24.14.1/x64/bin/node --no-warnings --enable-source-maps --experimental-loader file:///home/REDACTED/work/frodo-cli/frodo-cli/dist/loader.cjs /home/REDACTED/work/frodo-cli/frodo-cli/dist/app.cjs shell k/frodo-cli/node_modules/.bin/sh (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Create a PR in rockcarver/frodo-cli to fix integration-batch workflow output formatting.

Context: A dry-run of Integration Batch workflow failed with:

• Unable to process file command 'output' successfully.
• Invalid format ' {'
  Cause: multi-line JSON is being written to $GITHUB_OUTPUT.

Required changes in .github/workflows/integration-batch.yml:

• Whenever writing JSON to $GITHUB_OUTPUT (e.g., prs_json, selected, skipped, merged, merge_skipped), ensure it is single-line/compact JSON using jq -c.

Specifically:

1. In 'Compute candidate PR list...' step, write prs_json as compact JSON.
2. In 'Filter to PRs with successful combined status' step, write selected and skipped as compact JSON.
3. In 'Merge selected PRs...' step, write merged and merge_skipped as compact JSON.

Do not change other behavior beyond what is necessary to fix the output formatting.

Add/keep job summary robustness as-is; the primary fix is compact JSON outputs.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: 1. yes
2. propose the necessary changes for a switch to labels

Assistant: Here’s a concrete proposal to switch the release-type decision from “trigger phrases in comments/title” to labels, while keeping your key requirement:

• Every push to main still produces a prerelease by default
• Patch/minor/major become explicit, non-accidental, and work cleanly with the new integration PR model

I’ll outline (1) the labeling scheme, (2) what changes in pipeline.yml, (3) what changes in docs/PIPELINE.md, and (4) migration plan.

---

1) Label scheme (simple and explicit)

Add exactly one of these labels to the PR you intend to merge into main (usually the integration PR):

• release:patch
• release:minor
• release:major

If none are present → prerelease (current default behavior).

Optional: you can also support release:prerelease, but you don’t need it because “no label” already means prerelease.

Precedence / validation rules

• If multiple release labels are present, pick highest (major > minor > patch) or fail the pipeline.
  I recommend fail (safer, forces clarity).

---

2) Changes needed in .github/workflows/pipeline.yml

Why this is slightly tricky

Your pipeline runs on:

• push to main (this is what actually releases)
• pull_request to main (CI only)

On a push event you don’t directly have “the PR that was merged” unless you look it up via the GitHub API. So the pipeline needs a small step:

1. Find the PR(s) associated with the merge commit / pushed SHA
2. Read their labels
3. Decide bump type
4. Pass that to phips28/gh-action-bump-version

Minimal implementation strategy

Add a step in the build job (only for non-PR events) that:

• calls GitHub API to find PRs associated with ${{ github.sha }}
  • endpoint: GET /repos/{owner}/{repo}/commits/{ref}/pulls (GitHub supports this)
• extracts labels
• sets an output like bump=patch|minor|major|prerelease

Then update phips28/gh-action-bump-version config so it bumps based on that bump value.

Two ways to wire bump into gh-action-bump-version

A) Easiest if supported: set default: dynamically and/or set version-type:/bump-type: input (depends on the action; we’d confirm supported inputs before editing).

B) Reliable fallback: keep the action, but control the trigger wording by injecting a synthetic “wording” into the commit message or tag step (messy; I don’t recommend).

Given you already rely heavily on phips28/gh-action-bump-version, the right approach is to adjust its inputs to accept an explicit bump type (if it supports it). If not, we should replace it with a small script that runs npm version (or node-based semver bump) deterministically.

My recommendation: if phips28/gh-action-bump-version doesn’t support explicit bump type cleanly, switch to a small custom step to bump version (it will be simpler than continuing to game “wording”).

---

3) Updates needed in docs/PIPELINE.md

Changes to the docs should say:

• Release type is determined by labels on the PR merged to main, not text triggers.
• Default remains prerelease if no release:* label is present.
• Add a section explaining how the integration workflow fits:
  • label individual PRs integration-batch to include them in integration
  • when ready to do a stable bump, put release:patch|minor|major on the integration PR before merging it

Also remove the scary warning about “don’t accidentally type PATCH RELEASE in comments”.

---

4) Migration plan (safe rollout)

1. Add the labels (release:patch, release:minor, release:major) in the repo.
2. Update pipeline.yml to:
   • prefer labels if present
   • otherwise fall back to prerelease
   • (optionally) keep the old trigger phrase support for 1–2 weeks, then remove it
3. Update docs/PIPELINE.md to match.
4. Announce: “Stop using trigger p...

This pull request was created from Copilot chat.