Fix bash syntax error in sync-pr-to-issue workflow when PR body contains special characters

[Copilot]

Inlining ${{ github.event.pull_request.body }} directly into the bash script causes a syntax error when the PR body contains parentheses, backticks, quotes, or newlines — GitHub Actions renders the expression before bash parses the script.

Change

Pass the PR body as an environment variable instead of interpolating it inline:

# Before — unsafe: PR body rendered directly into bash source
run: |
  ISSUE=$(echo "${{ github.event.pull_request.body }}" | grep -oE '#[0-9]+' | head -n1 | tr -d '#')
  echo "issue_number=$ISSUE" >> $GITHUB_OUTPUT

# After — safe: PR body passed as env var, never touches bash syntax
env:
  PR_BODY: ${{ github.event.pull_request.body }}
run: |
  ISSUE="$(printf '%s' "$PR_BODY" | grep -oE '#[0-9]+' | head -n1 | tr -d '#')"
  echo "issue_number=$ISSUE" >> "$GITHUB_OUTPUT"

• env: PR_BODY — body is set by the runner before bash executes; special chars are never part of the script source
• printf '%s' over echo — avoids echo interpreting escape sequences
• Quoted $GITHUB_OUTPUT — minor correctness fix

Original prompt

Fix GitHub Actions workflow failure in job 70268323374 (workflow: .github/workflows/sync-pr-to-issue.yml) for PR #1559.

Observed failure (from job logs): bash reports syntax error near unexpected token '(' while running the step that extracts a linked issue number from the PR body.

Root cause: the workflow currently inlines ${{ github.event.pull_request.body }} directly into a shell script:

ISSUE=$(echo "${{ github.event.pull_request.body }}" | grep -oE '#[0-9]+' | head -n1 | tr -d '#')

When the PR body contains characters like backticks, quotes, parentheses, and/or newlines (as in PR #1559, which includes text about action_text-trix 2.1.17 and a bundle-audit vulnerability), the generated bash script becomes syntactically invalid.

Task:

• Update .github/workflows/sync-pr-to-issue.yml to safely extract the first #<number> from the PR body without injecting the raw PR body into the shell script.
• Recommended solution: pass PR body via env: PR_BODY: ${{ github.event.pull_request.body }} and then parse using printf '%s' "$PR_BODY".
• Ensure quoting is correct and the step writes issue_number to $GITHUB_OUTPUT.
• Keep the rest of the workflow behavior unchanged.

Acceptance criteria:

• Workflow no longer fails with bash syntax errors when PR body contains special characters.
• The extracted issue number output remains correct.
• CI for PR Bump action_text-trix 2.1.17 → 2.1.18 (GHSA-53p3-c7vp-4mcc) #1559 passes (at least the failing job is fixed).

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

User: Please find a solution for failing job 70268323374. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The failing job 70268323374 is not failing because of the bundle-audit vulnerability itself. It’s failing earlier due to a bash syntax error caused by unescaped characters from the PR body being injected into a shell script.

What’s happening

In .github/workflows/sync-pr-to-issue.yml, the first step does:

ISSUE=$(echo "${{ github.event.pull_request.body }}" | grep -oE '#[0-9]+' | head -n1 | tr -d '#')

Your job log shows the PR body contains text like:

• backticks
• quotes
• parentheses
• newlines

Example from the log includes Level0InputController) and other punctuation. When GitHub Actions renders ${{ github.event.pull_request.body }} into the generated shell script, that content can break the script syntax, producing:

line 63: syntax error near unexpected token `('

So the fix is: don’t inline the PR body into the shell script. Pass it via an environment variable (or use github-script), and then parse it safely.

Fix (recommended): pass PR body via env and parse it

Update the “Extract linked issue number from PR body” step like this:

- name: Extract linked issue number from PR body
  id: extract
  env:
    PR_BODY: ${{ github.event.pull_request.body }}
  run: |
    ISSUE="$(printf '%s' "$PR_BODY" | grep -oE '#[0-9]+' | head -n1 | tr -d '#')"
    echo "issue_number=$ISSUE" >> "$GITHUB_OUTPUT"

Key changes:

• uses env: PR_BODY: ... instead of embedding the body directly in the script
• uses printf '%s' to avoid echo edge cases
• quotes variables consistently

This prevents PR text (including parentheses/backticks/quotes/newlines) from being interpreted by bash.

Alternative fix: extract issue number using actions/github-script

If you prefer avoiding shell parsing entirely:

- name: Extract linked issue number from PR body
  id: extract
  uses: actions/github-script@v8
  with:
    script: |
      const body = context.payload.pull_request.body || "";
      const m = body.match(/#(\d+)/);
      core.setOutput("issue_number", m ? m[1] : "");

Either approach will stop the syntax error and allow the rest of the workflow to run normally.

Note on the vulnerability text in the logs

The action_text-trix 2.1.17 / “update to >= 2.1.18” message appears to just be part of the PR body content that this workflow tried to parse, not the root cause of this job failing. The root cause here is the unsafe interpolation of PR body into bash.

User: fix the issue please

Assistant: I’ve queued the workflow fix (safe issue-number extraction by passing the PR body via an environment variable instead of inlining it), and we’re now waiting on your approval in the dialog to apply the change to the repository and push the update.

User: @Copilot Accepted Confirmation: Are you sure?

Assistant: You can fix it by changing the workflow step that extracts the issue number so it doesn’t inline the PR body into the bash script (that’s what’s causing the syntax error near unexpected token '(' when the PR body contains punctuation/newlines).

Apply this patch to .github/workflows/sync-pr-to-issue.yml:

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud