Develop

[loganathan-sekaran]

No description provided.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)

• develop

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

In general, the fix is to avoid using ${{ github.event.pull_request.head.ref }} directly in run: commands. Instead, assign it to an environment variable via the env: block and then reference it using the shell’s native syntax (e.g., $HEAD_REF) within the script. This prevents the GitHub expression engine from injecting untrusted content directly into the shell command line and confines any untrusted characters to a single argument position.

Concretely, we should:

• For the git clone command, move github.event.pull_request.head.ref into an env var (e.g., HEAD_REF) and then use git clone -b "$HEAD_REF" ... in the script. Even though that line is commented out, we should fix the pattern so it is safe if re-enabled.
• For the git push command, likewise pass both the head ref and the repo full name via env: as HEAD_REF and HEAD_REPO_FULL_NAME, and then use them as $HEAD_REF and $HEAD_REPO_FULL_NAME inside the shell script. This eliminates ${{ github.event.* }} from the run: body.

We will modify:

• The “Clone the repository” step to add an env: section with HEAD_REF and HEAD_REPO_FULL_NAME, and update both the commented and active git clone commands to use $HEAD_REF and $HEAD_REPO_FULL_NAME.
• The “Commit and push changes” step to add an env: block with HEAD_REF and HEAD_REPO_FULL_NAME, and update the git push line to use standard shell variable syntax.

No new imports or external packages are needed; we only change the YAML workflow configuration.

In general, to fix code injection issues in GitHub Actions, you should avoid using untrusted expressions directly in run: or script contexts. Instead, assign the expression to an environment variable via env: and then reference it using the shell’s native syntax ($VAR) inside the script, making sure it is properly quoted.

For this workflow, the best targeted fix is to move ${{ github.event.pull_request.head.ref }} into an environment variable (for example, PR_HEAD_REF) and use $PR_HEAD_REF in the git clone command. This keeps behavior identical—Git still clones the same branch from the same repository—but the untrusted value is no longer interpolated into the script as GitHub expression syntax at evaluation time. We will update only the “Clone the repository” step in .github/workflows/xlsx-to-csv.yml, adding an env: section and switching the git clone line to use $PR_HEAD_REF. No additional imports or external dependencies are needed.

Generally, to fix this class of problems in GitHub Actions, untrusted expressions like ${{ github.event.pull_request.head.ref }} should not be interpolated directly into the shell in run: blocks. Instead, assign them to environment variables using workflow expression syntax and then reference them using the shell’s own variable expansion ($VAR). This prevents the workflow expression engine from injecting raw user-controlled strings directly into the shell script.

In this specific case, we should (1) move github.event.pull_request.head.ref and github.event.pull_request.head.repo.full_name into environment variables for the “Commit and push changes” step, and (2) use those variables as $PR_HEAD_REF and $PR_HEAD_REPO_FULL_NAME inside the shell script. This keeps the existing functionality (push back to the pull request’s head branch in the fork) but avoids direct expression interpolation inside the git push command. No other behavior changes are needed, and no extra libraries are required; the only change is within the YAML for that step.

Concretely:

• Edit the “Commit and push changes” step at lines 53–59.
• Add an env: section under the step that sets PR_HEAD_REF and PR_HEAD_REPO_FULL_NAME from the existing expressions.
• Update the git push line to use $PR_HEAD_REPO_FULL_NAME and $PR_HEAD_REF instead of ${{ github.event.pull_request.head.repo.full_name }} and ${{ github.event.pull_request.head.ref }}.

In general, the fix is to explicitly declare minimal GITHUB_TOKEN permissions for this workflow or specific job(s) using a permissions: block, instead of relying on repository defaults. For a workflow that just checks out code and runs Docker/database commands, contents: read is sufficient for the entire workflow.

The single best fix here is to add a top-level permissions: block (so it applies to all jobs) with contents: read. This does not change existing functionality, because actions/checkout@v2 only requires read access to repository contents, and no steps modify GitHub resources. Concretely, in .github/workflows/push-trigger.yml, insert:

permissions:
  contents: read

between the on: block and the existing env: block (around current line 18). No imports, methods, or additional definitions are required, since this is purely a workflow configuration change.

In general, fix this by explicitly declaring a permissions: block for the workflow or for the specific job, granting only the scopes required. This overrides repository defaults and constrains the GITHUB_TOKEN used within the job.

For this workflow, the steps only need to read repository contents and call GitHub’s REST API to read PR commits and metadata. All write operations to the repository use secrets.ACTION_PAT, not GITHUB_TOKEN. Therefore, we can set permissions: contents: read at the workflow or job level. Because the warning is on the job line (runs-on: ubuntu-latest), the clearest fix with minimal behavioral change is to add a permissions: block under the convert_xlsx_to_csv job, before runs-on.

Concretely:

• Edit .github/workflows/xlsx-to-csv.yml.
• Under jobs: convert_xlsx_to_csv:, insert:

    permissions:
      contents: read

• Keep indentation consistent (two spaces per level).
  No new imports, methods, or additional configuration are required.