It would be useful if the action required to make a PR un-stale were pushing a new commit on that PR -- not just adding a comment to the PR.
It could very well/likely be that the PR is actually conflicting with the base branch and needs those conflicts worked out in any case.
But even if it is not, requiring the PR owner to push a commit raises the bar just a bit higher making a PR owner consider if the PR is worth their time to at least push a new commit rather than simply having to add a comment.
Additionally, a new commit makes any CI/CD activity on that PR trigger, which can be helpful for certain CI/CD systems. Jenkins for one, can apply retention rules for historic runs/data on a PR but those retention rules are only triggered when a PR is activated in Jenkins. So in the least, requiring a user to push a commit to the PR allows Jenkins to apply it's prescribed retention rules on the historic data on that PR. This of course is just one example.
PandaSuits
commented
2 years ago
It would be useful if the action required to make a PR un-stale were pushing a new commit on that PR -- not just adding a comment to the PR.
It could very well/likely be that the PR is actually conflicting with the base branch and needs those conflicts worked out in any case.
But even if it is not, requiring the PR owner to push a commit raises the bar just a bit higher making a PR owner consider if the PR is worth their time to at least push a new commit rather than simply having to add a comment.
Additionally, a new commit makes any CI/CD activity on that PR trigger, which can be helpful for certain CI/CD systems. Jenkins for one, can apply retention rules for historic runs/data on a PR but those retention rules are only triggered when a PR is activated in Jenkins. So in the least, requiring a user to push a commit to the PR allows Jenkins to apply it's prescribed retention rules on the historic data on that PR. This of course is just one example.