Skip to content

Pull and Merge Requests

The Pull Requests view lists the project’s GitHub pull requests or GitLab merge requests with their test results. Each row shows the request and a status breakdown of its tests, with segments linking into the detailed report. For GitHub projects, the same classification powers the Flakiness.io check posted on the pull request.

When tests run on a pull or merge request, Flakiness.io:

  1. Collects test data from all test runs associated with the request.
  2. Compares results against the target branch history to classify each failure. An existing test with a perfect recent history on the target branch that now fails is a regression. A test that has been flaky or failing on the target branch is not.
  3. Flags brand-new tests that fail (tests the request adds that don’t pass) as regressions too.
  4. Reports status back to GitHub via a Flakiness.io check when the project is connected to GitHub.

The check badge has three outcomes:

  • Mergeable — no failures and no regressions in this PR. Everything passes.
  • Has Regressions — the PR either breaks a previously-passing test with a perfect history, or adds a new test that fails on first run. Investigate before merging.
  • Neutral — there are failures, but the same tests have also been failing or flaking on the target branch recently. They might be noise, or they might be real — Flakiness.io can’t say for sure. Worth a look before merging.

Open-source projects that accept contributions from forks need a slightly different setup because GitHub doesn’t expose secrets or OIDC to fork-PR workflows. See GitHub Actions for Open Source Projects for the two-workflow pattern.