Gitfence
Start free

What contractors see from CI

Show contractors why CI failed without exposing hidden code: results, error locations, filtered logs, MCP and REST access, re-runs and audit records.

Short answer: CI runs on the full repository, but contractors do not need to see everything it prints. Gitfence shows them why their CI failed without showing hidden code, hidden file paths, stack traces through hidden code, secrets or encoded data. An admin chooses results, error locations or filtered logs for each repository.

Steps

  1. Choose the repository level. Open the repository's Settings and find What contractors see from CI. Choose one of the three levels below. Results and error locations is the default.
  2. Open the pull request's Checks tab. In the member web UI, open a pull request and choose Checks. This works on every pull request the member can see: their own and ones the team shares with them. The same filtering applies to both.
  3. Read the failure. Every level shows checks and statuses. Error locations and the failing step's log appear when the repository level allows them. A log starts with 40 lines; choose Show more for up to 400.
  4. Re-run a failure if allowed. On their own pull request, a person can re-run a failed GitHub Actions job or every failed job in its workflow run. Other CI is asked to run the check again.

The three levels

Setting What the contractor sees
Results only Each check and status with its name, result, duration and the step that failed. Nothing CI printed.
Results and error locations The results, plus GitHub check-run annotations: file, line and a short message for files the person can see.
Results, error locations and filtered logs The results and locations, plus the filtered end of the failing step's log.

The middle level is the default because names, results and locations come from the team's own workflow config and GitHub. Location filtering follows the access rules exactly. Annotation messages are capped at 1,000 characters each and 50 per check, and are fingerprint-filtered.

An annotation on a file outside the person's access shows only An error in a file outside your access. It has no path, line or message.

With Results only, what a CI check wrote about itself (its summary, a status's description) is left out everywhere, including the merge box at the bottom of the conversation. Gitfence's own checks keep their text.

Agents and REST

Agents use the MCP tools pull_request_checks, check_log and rerun_check. The REST endpoints are:

  • GET /api/collab/repos/<owner>/<repo>/pulls/<n>/checks
  • GET .../checks/<id>/log?lines=40, with up to 400 lines
  • POST .../checks/<id>/rerun?scope=job|failed

All responses are JSON. The same pull request access and filtering apply here too.

How output is filtered

The filters apply to everything shown: names, titles, messages and log lines.

  • Line cleanup. Every line is cut to 2,000 characters. Terminal colour codes, control characters and text-direction characters are stripped.
  • Hidden paths. A line that points into a hidden file or folder is hidden whole and replaced by [gitfence: line hidden, it points into code outside your access]. This covers absolute runner paths, relative paths, stack frames, URLs and a bare file name only hidden files have.
  • Hidden-code fingerprints. This is the same filter used on pull request conversations. A line quoting hidden code, its reverse, or base64 or hex of it is replaced by [gitfence: line redacted, it contained fenced code]. Long random-looking base64 or hex runs are removed.
  • Secrets. The secret detectors Gitfence uses on files replace credentials with [secret hidden by Gitfence]. Logs get a stricter pass on top: a value in an Authorization header, a password in a URL, or a value after a name such as TOKEN= or password: is hidden whatever it looks like. GitHub's own *** mask stays.
  • Types only. These files count as hidden for CI output because their implementation is hidden.

Re-running CI

The repository setting Contractors can re-run CI on their pull requests is on by default. Re-runs work only on the person's own pull requests, not shared ones. Each person gets ten re-runs per hour, and every re-run is recorded in the audit log.

GitHub Actions jobs need the GitHub App permission Actions: Read and write. Other CI needs Checks: Read and write. If one is missing, Gitfence says which, and everything else keeps working.

Logs and audit

Raw logs are streamed from GitHub. Only the failing step's last 400 lines are kept in memory, and nothing is stored. Every log view is recorded in the audit log with who viewed it, which pull request and check, and how many lines were shown and redacted.

Honest limits

  • Logs are an explicit choice. They are the biggest channel because they contain whatever the code under test prints. A test the contractor wrote runs next to hidden code, so it could print hidden code disguised in a way no filter recognises. This is the same honest limit as Fenced CI's redacted output.
  • Filtering fails closed. If Gitfence's filter for the repository isn't ready yet or can't be read, the log isn't UTF-8 text, it grows beyond 128 MB before the failing step ends, or reading and filtering takes too long, the person sees Log hidden: ask an admin. Check names, results and location-only annotations still show.
  • Commit statuses have no log. Older CI integrations that report commit statuses show only a name, result and description.

Next: code review and AI agents and MCP.

Related guides