You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
When developer activity exceeds underlying build capacity, there is no mechanism to throttle activity.
Current behavior
All PRs are built.
Suggestion
Using draft PRs to solicit early feedback is a common practice. In this case, the author likely doesn't need a build check to run, so these could be a natural candidate to skip triggering builds.
Alternative/additional
GitHub PRB uses labels to flag whether a build should be triggered, or not. Labels are more flexible, but in practice there are tradeoffs in finding a good default (Does everyone know about the label? Are they thinking about being conscious of build infrastructure in order to think to apply it? Do you choose no builds by default, and then field questions about how the developer can get a build to trigger?
Summary
Using draft as a signal for the default behavior, and then supporting a label to override the default could be a good balance of providing reasonable default behavior with respect to infrastructure that mostly just works, but can be overridden if desired (The desire being to get a build while the PR is in draft).
At least using draft as a signal with no additional label override would provide a workable mechanism to throttle activity in a way that aligns with current developer workflows.
The text was updated successfully, but these errors were encountered:
The main problem I see with this is that it's the opposite of GitHub Actions' default (correct?). I.e., if a project is using LPRB, Draft PRs don't get tested. But if a project is using GitHub Actions, draft PRs will get tested by default.
That could be confusing behaviour for developers who work in multiple repositories.
That's a good point. It's possible for a workflow to include a guard or use the ready_for_review type to implement a "skip when draft", but, that isn't the platform default. An equivalent feature would be to use a property in the Leeroy config, "buildDraftPRs".
However, a repo that doesn't build drafts by default, whether implemented in workflows or Leeroy could be confusing for the same reasons.
I'd be happy to modify this request (and associated PR) to "Add a mechanism to skip triggering builds", and just add support for a skip-builds label (removing the checks around draft status).
Problem
When developer activity exceeds underlying build capacity, there is no mechanism to throttle activity.
Current behavior
All PRs are built.
Suggestion
Using draft PRs to solicit early feedback is a common practice. In this case, the author likely doesn't need a build check to run, so these could be a natural candidate to skip triggering builds.
Alternative/additional
GitHub PRB uses labels to flag whether a build should be triggered, or not. Labels are more flexible, but in practice there are tradeoffs in finding a good default (Does everyone know about the label? Are they thinking about being conscious of build infrastructure in order to think to apply it? Do you choose no builds by default, and then field questions about how the developer can get a build to trigger?
Summary
Using draft as a signal for the default behavior, and then supporting a label to override the default could be a good balance of providing reasonable default behavior with respect to infrastructure that mostly just works, but can be overridden if desired (The desire being to get a build while the PR is in draft).
At least using draft as a signal with no additional label override would provide a workable mechanism to throttle activity in a way that aligns with current developer workflows.
The text was updated successfully, but these errors were encountered: