Only check pull requests targeted at specific branches

[chapulina]

We have a use case where we'd like to enable DCO for a few branches of a repository, but not others.

We know we can make it required according to the branch, but it would be good to completely disable the check for other branches so we don't "spam" contributors targeting pull requests at those branches.

Maybe that feature could be exposed through .github/dco.yml?

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[chapulina]

Yes, that's still a use case we're interested in.

[gr2m]

Thanks for letting us know. Right now it does not to seam to be a common enough uses case to make the additional complexity worth it, as no other users asked for it. I’d suggest we leave the issue open to see if there is more interest.

If this is becoming a blocker for you, I’d suggest to send a pull request that implement the changes you need and deploy your fork with a custom GitHub app registration.

[hiimbex]

Agree, I don't think this is something we should do.

Even for a long lived feature branch they would eventually get merged to the default branch, so I can't see a reason why this is desirable. If you need a true 'development' repo to make commits to, I'd recommend disabling the app on the whole repo.

[chapulina]

Our use case is not about feature branches, but about having 2 separate release tracks that are similar enough to live in the same repository, but will never be merged together.

In case anyone is interested, this is one of the repositories where we would use this: https://github.com/ros/class_loader. Branches ending in -devel are release branches for an older version of the software, to which we don't require DCO checks. Newer release branches (ardent, bouncy, crystal...) need to enforce DCO.

Thank you for considering anyway.

GitHub

ros/class_loader

ROS-independent library for dynamic class (i.e. plugin) introspection and loading from runtime libraries - ros/class_loader

[hiimbex]

I'd recommend using protected branches to conditionally enforce the check on 'new' branches (you can use regex): https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuring-protected-branches & https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/enabling-required-status-checks specifically

So basically have it as a required status check only on those branches, and then have it still report but be non-blocking on your -devel branches

Configuring protected branches - GitHub Docs

If you're a repository owner or have admin permissions in a repository, you can customize branch protections in the repository and enforce certain workflows, such as requiring more than one pull request review or requiring certain status checks to pass before allowing a pull request to merge.

Enabling required status checks - GitHub Docs

Repository administrators can enforce required status checks before a branch is merged in a pull request or before commits on a local branch can be pushed to the protected remote branch.

[chapulina]

Thank you for the suggestion. We were hoping not to show the check at all unless it's required, in order not to throw off contributors.