Migrating CI from the Bash Uploader to the Codecov Uploader binary: safe rollback and unclear patch status behavior

When migrating from the deprecated Bash Uploader to the standalone Codecov Uploader binary pinned to a specific release SHA, the upload step itself is stateless. This means that if the new binary misbehaves, pinning the previous version restores the upload mechanism, but the configuration in codecov.yml—project and patch status checks—may continue to affect merge gates independently of the uploader version.

Rollback safety

Reverting the pinned binary version alone is usually sufficient to restore uploads, but any codecov.yml changes that adjust project or patch status checks will persist. If those checks are set to block merges (e.g., required status checks on protected branches), they can still reject a pull request even though the coverage upload now uses the old binary. Therefore, a clean rollback should also revert any codecov.yml modifications made during the migration, or at least confirm that the existing yaml still produces the desired status outcomes.

Patch‑status consistency with informational: true and carryforward flags

The combination of informational: true patch checks and carryforward flags for partial builds can produce coverage calculations that differ between the Bash Uploader and the binary release. The binary’s coverage‑parsing logic has been refreshed in recent releases, and some edge cases (e.g., files only present in a partial build) may be handled differently. Empirical verification on a representative PR is required to confirm that the same patch‑coverage delta is reported.

Validating codecov.yml and status‑check behavior before full rollout

1. Create a dedicated test branch (or a feature‑branch PR) that uses the pinned binary SHA.
2. Run the usual CI job that uploads coverage with the binary and also runs the existing codecov.yml.
3. After the upload, open the Codecov UI and inspect the Patch tab and the commit‑status badge. Verify that the patch‑coverage delta, the informational flag indicator, and the carryforward flag behavior match the expectations from the pre‑migration Bash Uploader runs.
4. If discrepancies appear, adjust codecov.yml (e.g., tweak patch block settings, carryforward thresholds, or informational flags) until the UI reflects the desired outcome.
5. Once the test PR shows consistent results, promote the pinned binary and the final codecov.yml to the default branch.

Missing diagnostic detail

To determine whether a rollback will also unblock merges, it helps to know the branch‑protection rule that gates merges on the patch status check. If the rule treats the check as required, the yaml settings will continue to affect mergeability even after the binary is reverted. Please confirm the exact branch‑protection configuration so we can advise on whether a full yaml revert is needed.