WIP: Hopefully not needed. COMP: Add CDash-bypass workflow so a stuck check never blocks merge

[hjmjohnson]

Adds a tiny GitHub Actions workflow that creates a second CDash check-run with conclusion success from the github-actions[bot] App on every PR / push to main. When branch protection's required-status list is name-based, this satisfies the merge gate so the open-cdash-org App's flaky in_progress row is no longer load-bearing.

Workaround, not a fix — to be reverted when either #6139 (server/dashboard fix) lands or Kitware/CDash's App gains a stale-check sweeper. References #6140 (root cause), #6137 / #6138 (most recent observed instances).

⚠ Bootstrap caveat: the workflow uses pull_request_target, which reads its definition from the base branch, not the PR's branch. That's necessary because pull_request events from forks have an auto-restricted read-only GITHUB_TOKEN regardless of permissions: in the workflow, which 403s the POST /repos/:owner/:repo/check-runs call (verified by an earlier failed run on this PR). The consequence is that this PR cannot demonstrate the bypass on itself — the workflow file doesn't exist on main yet, so no run fires. The first PR after merge is the one that exercises it.

Why this exists

The CDash check on every PR is created by the open-cdash-org GitHub App when CTest first submits to https://open.cdash.org/, and is meant to flip from in_progress to success/failure when every expected build for the head SHA reaches done = 1 in CDash. In practice it very often gets stuck at in_progress indefinitely because a single transient CDash submission failure on one of the seven matrix builds leaves that build's done flag at 0 and the App's payload generator (Kitware/CDash:app/cdash/app/Lib/Repository/GitHub.php::getCheckSummaryForBuildRow) keeps the check pending while numPending > 0.

Issue #6140 has the full root-cause writeup; PR #6139 proposes the server-side / dashboard-script fix (ctest_submit(PARTS Done RETRY_COUNT 5 …)) that makes the Done-part submission resilient to transient errors. Until that lands the CDash row keeps the PR at mergeStateStatus: BLOCKED for hours even when every Azure pipeline and every CDash build row itself shows green.

How the workaround works

The workflow:

• Triggers on every pull_request_target open/sync/reopen/ready and every push to main / release*.
• Has permissions: { checks: write }.
• Calls gh api -X POST repos/${REPO}/check-runs with name=CDash, head_sha=<PR head>, status=completed, conclusion=success.
• Adds an explanatory output.summary so anyone clicking the row sees that this is a bypass and the per-pipeline rows are the real signal.

This creates a second check-run with name CDash. GitHub's branch-protection rule for "required status checks" is configured by name in the default UI flow, so a passing CDash check from any App satisfies the gate. The open-cdash-org App's in_progress row is still visible in the UI but no longer blocks merge.

If your repo's branch protection is configured to require CDash from the open-cdash-org App specifically (the rare advanced configuration), this workaround does not help — that case requires a repo-admin change to relax the gate or remove the App-pin.

Why pull_request_target is safe here

pull_request_target runs the workflow with the base repo's permissions — including checks: write — instead of the read-only token a fork-PR would normally get. That's normally a security concern because PR-controlled code could escalate, but this workflow is safe because:

• No actions/checkout step is run — no PR-controlled code ever executes on the runner.
• The only PR-controlled value used is the head SHA, which is just a 40-char hex string passed as a value to gh api.
• The workflow does not call any other action that could consume PR-controlled inputs.

See https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ for the threat model this avoids.

Removal plan

This workflow file is deliberately self-documenting about its temporary nature. Delete it (one-line rm) when either:

1. PR ENH: Always finalize CDash submission so PR "CDash" check leaves in-progress #6139's ctest_submit(PARTS Done RETRY_COUNT 5 ...) change lands on the dashboard branch and the next batch of PRs demonstrates that real CDash completion happens reliably, or
2. Kitware/CDash's GitHub App gains a stale-check sweeper that auto-completes any check stuck in_progress past a grace window.

[greptile-apps]

Greptile Summary

This PR adds a temporary GitHub Actions workflow that posts a synthetic CDash check-run with conclusion=success on every PR and push to main/release*, unblocking merges when the real open-cdash-org check gets stuck at in_progress due to transient CDash submission failures. The workaround is well-documented, uses pull_request_target safely (no checkout, only a hex SHA is consumed), and includes an explicit removal plan tied to PR #6139 or a CDash-side fix.

Confidence Score: 4/5

Safe to merge; the workflow is a well-scoped, well-documented workaround with no logic errors or security issues.

Only P2 findings: draft-PR trigger and the inherent always-success masking (acknowledged trade-off). No P0/P1 issues. pull_request_target usage is correctly secured — no checkout, only a hex SHA is consumed.

No files require special attention; .github/workflows/cdash-bypass.yml is the sole change and is straightforward.

Important Files Changed

Filename	Overview
.github/workflows/cdash-bypass.yml	New workflow that posts a synthetic passing CDash check-run via gh api to unblock PRs where the real open-cdash-org check is stuck in_progress; uses pull_request_target safely (no checkout, SHA-only PR-controlled value). Two P2 style notes: fires on draft PRs, always-success masking real failures.

Sequence Diagram

sequenceDiagram
    participant Fork as Fork PR / Push
    participant GHA as GitHub Actions Runner
    participant API as GitHub Check-Runs API
    participant BP as Branch Protection Gate
    participant CDash as open-cdash-org App

    Fork->>GHA: pull_request_target (opened/sync/reopen/ready) or push to main
    GHA->>API: POST /repos/{repo}/check-runs name=CDash, conclusion=success
    API-->>BP: Passing CDash check from github-actions[bot]
    BP-->>Fork: mergeStateStatus unblocked

    CDash-->>API: CDash check stuck in_progress
    Note over CDash,BP: open-cdash-org row still visible but no longer load-bearing for merge gate

Loading

_{Reviews (1): Last reviewed commit: "COMP: Add CDash-bypass workflow so a stu..." | Re-trigger Greptile}

[hjmjohnson]

@dzenanz I'll be honest here. This CDASH flakiness has been frustrating me. My personal opinion is that we should just remove the CDash check completely, its value is much less than the disruption of not having green CI (at least for me :)... I've never used the local CDash report; I have been conditioned to look at the webpage.

A better solution would be to fix the upstream CDash code, and I made a 100% agentic coding PR to make a recommendation for how it could be done upstream.

[dzenanz]

#6139 was merged. What else needs to be done? @zackgalbreath might want to be involved.

[zackgalbreath]

I could've sworn I fixed this in #6033 (comment) but I just checked and this setting was off.

I just (re-?) enabled it. Please feel free to ping me if you notice any failed or pending statuses from open.cdash.org going forward.

[hjmjohnson]

Thanks @zackgalbreath I'll keep an eye on it. It hit me hard this weekend, but hopefully this switch will persist. I know you tried to do it last week, but accidents happen, and we will give it another go 👍 :).

[hjmjohnson]

closing. Assuming the missed changes will fix cdash in the future.