app: DCO doesn't respect Verified status by GitHub
Bug Report
Current Behavior
When editing docs from GitHub, the DCO creates unnecessary hassle by the need to checkout the PR and amend it with -s
option. But GitHub already checked such commits and added Verified
label to them.
https://github.com/buildpacks/docs/commit/4b6354c0ee94e8731f4a329b3ec6cc4b3dcfeda0
DCO fails to validate them.
Expected behavior/code
DCO successfully detects verified commits and passes checks.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 16 (8 by maintainers)
The ‘verified’ indicator on github ensures the commit was signed with a GPG key. Signing your commit with a GPG key is not equivalent in most circles to agreeing to the DCO (in fact there was once a Probot app to enforce that alone! https://github.com/jarrodldavis/probot-gpg).
So please make sure the PR by default does not include this functionality and is opt-in only (by way of a config option in the
.github/dco.yml
)This does seem as if it’s still relevant, as the original point @abitrolly raised is still valid: Editing online via GitHub’s web interface results in “un-signed-off” commits. (Unless the user takes pains to manually type out a correctly-formatted “Signed-off-by:” trailer in their commit message… something absolutely nobody is going to do.) If a user editing via the web creates un-signed-off commits, they’re then forced to clone their fork locally, pull down the branch in question, check it out, amend their commit(s) with a signoff, and force-push them back to the PR branch. That’s a lot of friction.
The point is also well-made (IMHO) that this is probably better solved through a statement in the PR, than through signoffs on commits. It’s when a PR is created, that you really want to ensure that people have agreed to the DCO.
What’s more, now that GitHub supports PR templates, it’s even possible to include the actual text of the DCO in a PR template (as a comment only visible to authors). That text can then be followed by a checkbox like the one @abitrolly proposed above. That’s arguably a much more affirmative statement than adding
-s
to thegit commit
command, an action that doesn’t really give any reliable indication that the user has even seen the DCO text.this seems like a reasonable request, but this repository is for the probot framework. there is a dedicated repository for DCO. it would be better to file this issue there