Is there an existing issue for this?
Feature description
Today, the open-pull-requests-limit is implemented as a service-level capability rather than within the core logic. This creates unnecessary duplication and complexity for any libraries or tools that rely directly on core functionality, as they must reimplement or work around this constraint independently.
Additionally, this design makes it difficult to test this configuration option in isolation using the CLI, since the enforcement does not exist at the core level where such testing would naturally occur.
Moving this enforcement into the core layer would:
- Ensure consistent behavior across all consumers of core
- Reduce redundant implementations in downstream libraries
- Enable proper testing of pull request limits via the CLI
- Simplify overall architecture and improve maintainability
Proposed Change:
Introduce enforcement of open-pull-requests-limit within the core logic, making it a first-class constraint applied uniformly across all entry points.
Is there an existing issue for this?
Feature description
Today, the
open-pull-requests-limitis implemented as a service-level capability rather than within the core logic. This creates unnecessary duplication and complexity for any libraries or tools that rely directly on core functionality, as they must reimplement or work around this constraint independently.Additionally, this design makes it difficult to test this configuration option in isolation using the CLI, since the enforcement does not exist at the core level where such testing would naturally occur.
Moving this enforcement into the core layer would:
Proposed Change:
Introduce enforcement of
open-pull-requests-limitwithin the core logic, making it a first-class constraint applied uniformly across all entry points.