icon

Autofix CI

Commits and pushes any local file changes made by previous steps, then fails the build to trigger a fresh run.

Autofix CI detects uncommitted file changes left by previous steps (e.g. code formatters, linters with auto-fix, code generators) and automatically commits and pushes them back to the source branch. Inspired by autofix.ci for GitHub Actions.

After pushing, the step intentionally fails the build so that the unfixed commit doesn't pass any quality gates downstream. The newly pushed commit triggers a fresh CI run, which succeeds because the fixes are now in place.

Typical workflow placement

Place this step after any steps that may modify files (formatters, linters, generators) and before any steps that enforce quality gates (tests, lint checks). When the step finds changes to push, the build fails at this point and the quality gates run on the corrected commit in the next build.

How it works

  1. Detects changed files via git status (including untracked files by default)
  2. Aborts if any changed file is a Bitrise CI config (bitrise.yml, bitrise.yaml, .bitrise/**) to prevent privilege escalation
  3. Commits all changes using a bot identity (Bitrise Autofix)
  4. Pushes to the source branch (see Authentication below)
  5. Exits with failure so CI gates don't pass on the unfixed commit

What triggers a skip

The step exits successfully without doing anything in these cases:

  • Not a PR build: the BITRISE_PULL_REQUEST environment variable is not set. The step is designed for PR workflows; push builds are left untouched.
  • Fork PR: the PR source repository differs from the target repository. The step cannot push to a forked repository using the provided credentials.
  • No changes detected: there are no uncommitted modifications to commit.

Authentication

The step supports both HTTPS and SSH remotes — whichever the preceding Git Clone step configured.

  • HTTPS: The step uses the git_token (and optionally git_username) inputs to authenticate the push via git's credential helper protocol. Credentials are passed to the git push subprocess through environment variables and never written to disk or embedded in the remote URL.
  • SSH: If the repository was cloned over SSH and an SSH key is already loaded in the agent, the push uses SSH automatically. The git_token and git_username inputs are ignored for SSH remotes. Note that SSH deploy keys are typically read-only — if the push fails with a permission error, switch to HTTPS authentication using the git_remote_url and git_token inputs.

Security

If any changed file is bitrise.yml, bitrise.yaml, or anything under .bitrise/, the step aborts with an error instead of committing. This prevents a malicious PR from using the autofix mechanism to sneak CI configuration changes through an auto-commit.

Outputs

  • AUTOFIX_NEEDED: true if uncommitted changes were detected
  • AUTOFIX_PUSHED: true if the autofix commit was pushed successfully
  • AUTOFIX_FILE_COUNT: number of files included in the autofix commit

Similar steps

Activates Bitrise Remote Build Cache for subsequent Bazel builds in the workflows.

Activates Bitrise Remote Build Cache add-on for subsequent Gradle builds in the workflow

Activates Bitrise Build Cache features for React Native projects

Activates Bitrise Remote Build Cache add-on for subsequent Xcode builds in the workflow