Greptile Summary

This PR improves CI parallelism by removing the check (Linux type-check / lint / format) job from the macos job's needs list. The macos job now fans out directly after the lightweight docs-scope and changed-scope preflight jobs, matching the pattern already used by check-additional and other parallel jobs.

• The check job produces no artifacts consumed by macos; macos independently runs pnpm build and pnpm test.
• This eliminates the ~40-second delay observed in PR perf(inbound): trim dispatch and command startup imports #52374 where macOS queueing waited behind Linux check despite preflight already knowing native files were touched.
• The updated comment in the YAML correctly documents the new intent.
• No functional behaviour changes — both check and macos still run; they just run in parallel now.

Confidence Score: 5/5

• This PR is safe to merge — it is a one-line dependency removal with no data dependency implications.
• The check job produces no artifacts consumed by macos, and macos already performs its own checkout, install, and build steps. Removing the dependency is a pure parallelism win with zero risk of breaking the macOS job. The change is also consistent with how other jobs in this workflow already fan out from preflight.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into fix-ci-prefligh..." | Re-trigger Greptile}

🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🟡 GitHub Actions workflow uses mutable tags instead of pinned commit SHAs

Description

The CI workflow references multiple third-party GitHub Actions by mutable version tags (e.g., @​v6, @​v5) rather than pinned commit SHAs.

Why this is a security issue:

• GitHub Actions run with the workflow's permissions and can execute arbitrary code in the runner environment.
• Using a mutable tag means the code that executes can change without any change to this repository (e.g., upstream compromise or force-moved tags), enabling a supply-chain attack.
• This pattern appears in several jobs (e.g., actions/checkout, actions/setup-python, actions/cache, actions/setup-java, gradle/actions/setup-gradle, actions/upload-artifact, actions/download-artifact).

Vulnerable example (one of several occurrences):

- name: Checkout
  uses: actions/checkout@​v6

- name: Setup Python
  uses: actions/setup-python@​v6

Recommendation

Pin all third-party actions to an immutable commit SHA, and (optionally) keep a comment with the intended tag for readability.

Example:

- name: Checkout
  uses: actions/checkout@<FULL_COMMIT_SHA> # v6

- name: Setup Python
  uses: actions/setup-python@<FULL_COMMIT_SHA> # v6

- name: Cache
  uses: actions/cache@<FULL_COMMIT_SHA> # v5

Additionally:

• Enable Dependabot version updates for GitHub Actions so SHA pins stay up to date.
• Consider restricting GITHUB_TOKEN permissions at the workflow/job level (permissions: {} then add only what is needed).

2. 🟡 Unverified download and execution of Android SDK commandline-tools in CI (supply-chain RCE risk)

Description

The Android CI job downloads and installs Android SDK cmdline-tools via curl and unzip without any integrity verification (checksum/signature), then adds the extracted sdkmanager to PATH and executes it.

This creates a supply-chain/RCE risk:

• External executable content is fetched at runtime from https://dl.google.com/....
• The archive is not verified (no pinned SHA256/SHA512, no signature validation).
• The workflow then executes binaries/scripts from the extracted archive (sdkmanager) during the job.

If the download were ever tampered with (upstream compromise, dependency swap, TLS termination compromise, etc.), the attacker would gain code execution on the CI runner in the context of this workflow.

Vulnerable snippet:

curl -fsSL "$URL" -o "/tmp/${ARCHIVE}"
unzip -q "/tmp/${ARCHIVE}" -d "$ANDROID_SDK_ROOT/cmdline-tools"
...
echo "$ANDROID_SDK_ROOT/cmdline-tools/latest/bin" >> "$GITHUB_PATH"
...
sdkmanager --sdk_root="${ANDROID_SDK_ROOT}" --install ...

Recommendation

Add integrity verification for the downloaded archive, or use a dedicated setup action that performs verification.

Option A: Pin and verify a SHA-256 hash in the workflow (update hash when bumping CMDLINE_TOOLS_VERSION):

CMDLINE_TOOLS_VERSION="12266719"
ARCHIVE="commandlinetools-linux-${CMDLINE_TOOLS_VERSION}_latest.zip"
URL="https://dl.google.com/android/repository/${ARCHIVE}"
EXPECTED_SHA256="<PINNED_SHA256_FOR_THIS_ARCHIVE>"

curl --fail --location --silent --show-error "$URL" -o "/tmp/${ARCHIVE}"
echo "${EXPECTED_SHA256}  /tmp/${ARCHIVE}" | sha256sum -c -

unzip -q "/tmp/${ARCHIVE}" -d "$ANDROID_SDK_ROOT/cmdline-tools"

Option B: Prefer a maintained GitHub Action for Android SDK setup (reduces custom install logic and can centralize best practices), and still pin action versions.

Analyzed PR: #52467 at commit 9cf152b

_{Last updated on: 2026-03-22T20:43:28Z}