Allow configuration for more autofix iterations

[vivodi]

Currently, autofix-ci appears to limit the number of autofix commits to a maximum of three per pull request. While this is a sensible default to prevent infinite loops, it can be restrictive for projects that require more than three distinct autofixing tasks.

In my project, I have configured multiple workflows to run autofix-ci on a pull request. This is because I don't need to run all autofix jobs for every pull request, only those that modify specific file paths. This approach allows me to have more granular control over which autofix tasks are executed.

For example, I have one workflow that syncs uv.lock when it's modified, and another that cleans up test cassettes when files in tests/cassettes are changed.

Here are my workflow configurations:

autofix-uv.lock.yml

name: autofix.ci
on:
  pull_request:
    paths:
      - uv.lock
jobs:
  uv-lock:
    name: sync uv.lock
    runs-on: ubuntu-latest
    steps:
      ...
      - uses: autofix-ci/action@v1

autofix-cleanup-cassettes.yml

name: autofix.ci
on:
  pull_request:
    paths:
      - tests/cassettes
jobs:
  cleanup-cassettes:
    name: clean up cassettes
    runs-on: ubuntu-latest
    steps:
      ...
      - uses: autofix-ci/action@v1

With this setup, it's entirely possible that a single pull request could trigger more than three autofix jobs. However, it seems that autofix-ci stops creating new fixup commits after the third one.

While the documentation suggests that all autofixing steps should be combined into a single job with a single call to the autofix-ci action, this is not ideal for my use case as it would trigger all autofixing jobs regardless of the files changed in the pull request.

It would be beneficial to have the ability to configure a higher limit for autofix iterations, or for autofix-ci to better support the use of multiple, path-scoped workflows. This would provide greater flexibility for complex projects with diverse autofixing needs.

Proposed Solution

It would be very helpful to make this limit configurable. I suggest adding a new input parameter to the autofix-ci/action. This would allow users to override the default limit when they are confident their setup will not cause an infinite loop.

Here is an example of how it could work:

- uses: autofix-ci/action@v1
  with:
    # New parameter to allow up to 5 fixes
    max-fixes: 5