We are getting PRs with DCO required stuck in waiting for status reported. I had one in that state to show which I reported on #69 but could not leave that PR in a state to be inspected as the patch had to land so that we can make progress.

But that is only one of many instances my users have reported this probot being stuck in waiting for status reported.

We hit a recent issue: envoyproxy/envoy#1743

Ideally it would be nice to see if we can check all emails associated with the GitHub id, one of those should match what's in the Signed-Off-By email IMHO.

There are many times when a new contributor summits a PR and forgets to do the signed off by.

It would be great if the bot could allow commits associated with the PR to be rewritten by allowing the contributor to comment: "please sign off my commits" or something to that nature

We are using the DCO probot on the ofiwg/libfabric Github project (thanks for this plugin!). We currently have a custom github webhook plugin that does the same thing as the DCO probot, but would love to ditch it in favor of the DCO probot. Currently, we are running both of them until we're happy with the DCO probot -- and then we'll turn off our custom hook.

On ofiwg/fabtests#689, the DCO probot returned a failure, but our Signed-off-by-checker returned a success. Visually inspecting every commit, it looks like every one of them is signed off properly. We're not quite sure why the DCO probot failed.

Looking at https://github.com/probot/dco/blob/master/lib/dco.js#L7, I'm wondering if the DCO probot failed because the commit author was:

Author: Neil Spruit <[email protected]>

But the signed off line was:

Signed-off-by: nrspruit <[email protected]>

Is the DCO probot failing because the names don't match between the two?

FYI: @shefty @nrspruit

https://sentry.io/probot/dco/issues/345257325/

Error: {"message":"Validation Failed","errors":[{"resource":"Status","code":"custom","field":"description","message":"description is too long (maximum is 140 characters)"}],"documentation_url":"https://developer.github.com/v3/repos/statuses/#create-a-status"}

Error: {"message":"Validation Failed","errors":[{"resource":"Status","code":"custom","field":"description","message":"description is too long (maximum is 140 characters)"}],"documentation_url":"https://developer.github.com/v3/repos/statuses/#create-a-status"}

Affecting this PR: tunnckoCore/parse-function#49 (heads up @charlike)

(This is an alternative suggestion for #74)

To my understanding, the legal requirement is that each commit must be signed to prove that the authors themselves signed these off, and that's the only authenticated way to do so. I am wondering if a GitHub comment that is from the commit author could fulfill the same requirement? That way a simpler way for signing off contributions could be implemented.

In essence, a committer would comment something like "/dco-approve" and it'll make the bot consider all previous commits as signed off.

This functionality will be enabled by a config file field.

Would be happy to implement this if this makes sense.

It would be great to be able to do more fine-grained organization-wide configuration, such as being able to set default value for require_signoff_for_members #52

Hi,

I started using this application for a few repositories and it's really useful, thanks!

I would now like to enable it for my company's github organisation that has both public and private repositories. I want the checks for all the public repositories, but not for the private ones. Currently the only way to do so is to manually specify the list of all public repositories, which is painful as we have about 150 public repositories, with new repositories being created from now and then.

For my case, the best would be to enable the checks via a setting in the .github/dco.yml file.

The DCO is required for all committers and on every non-merge commit for most projects. Having the 'Set DCO to Pass' option removes the paper trail of having commits specifically signed off on.

It would be great to have a config option to have that button not enabled.

The dependency probot was updated from 7.2.0 to 7.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

probot is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Hello DCO users!

We recently updated the DCO to utilize the new checks API. This means that we can now explain to users more easily how to add their sign-off to commits. We hope you’ll accept this permissions update to make the user experience for DCO users easier. In the meantime, we will be offering backwards compatible support for statuses until permissions are updated.

Check it out in action here.

You might notice a new button on that screen if you have WRITE access to a repo using the DCO. That button will automatically set the app's status to passing.

You can learn more about the process we went through to update the app here: #79. Feel free to comment any feedback or let us know if you have any questions/concerns or run into any problems.

I get the following feedback from DCO:

Commit sha: 96310b2, Author: Tim Müller-Seydlitz, Committer: Tim Müller-Seydlitz; Expected "Tim Müller-Seydlitz [email protected]", but got "Tim Müller-Seydlitz [email protected]".

Are "ü" and hyphenated names not properly treated?

We just replaced CLA with DCO and started to use this app for all public Gradle repositories.

Our primary motivation was to reduce friction for external contributors and automate the process. In our case, the DCO is not legally needed for Gradle employees that sign separate agreements. Internally we tend to submit our own changes through pull requests too. From what I see the choice we have is either to:

• Sign off our own commits
• Merge internal PRs with failed DCO checks

I was originally thinking that we would just sign off our own commits. However, one of the engineers brought up the point that it would bloat commit messages a bit for something that is not really necessary. The only reason to sign off our own commits would be to make checks done by probot/dco pass.

Ideally, there would be an option to distinguish between external contributions and contributions from the members of given GitHub organization so that the DCO checks can be skipped for the latter.

When using the GH interface to accept a change DCO bot rejects the automatically generated commit even when the Signed-off-by message was correct.

In my opinion, Co-Authored-By message (automatically introduced by GitHub UI) should be ignored.

We had a case where someone signed off a commit with an invalid email address, it would be nice if the bot caught this: envoyproxy/envoy@981375f

Shouldn't the bot be checking against a valid email associated with the GitHub id?

There seems to be an issue here edgexfoundry/edgex-go#376
where the commit is not signed, but the DCO check still passes. Perhaps I'm overlooking something?

When there is a case where a commit isn't signed off, we should link to instructions or give projects the ability to link to instructions on how to do this.

"I saw that you didn't sign off your commit, do this...". "I saw that you signed off your commit with XXX but the linked account shows your email as YYY"

The DCO does not require that the sign-off must be from the author, e.g.: https://lkml.org/lkml/2004/5/25/126

Would it be possible not to fail but warn in the case if commits are signed but not by the author?

Currently, this GitHub Integration will check commits in a Pull Requests to verify that all of them have the DCO sign-off. See #2 for a demo. As the README documents, you can use require statuses to require that the DCO check passes before allowing a pull request to be merged.

What other features are desired for DCO integration?

cc @mkdolan @caniszczyk

Today, a lot of PRs came in from Dependabot. Unfortunately, none of them have been approved by the DCO bot.

After reading through #69 and #111, I tried to force push one branch and get DCO bot to react, but that didn't help. Any other ideas?

PS: Thanks for the work! You have no idea how much work and headache you saved us :)

We've got several projects that have the DCO probot integration configured and since sometime on at least Thursday (2017-08-31) or Friday (2017-09-01) last week all the checks are just sitting there with 'DCO — Waiting for status to be reported' for the check.

Two things related to this:

1. Any idea how to retrigger checks that are integrations?
2. Any idea when this is going to be fixed?

Hi, https://github.com/coreinfrastructure/best-practices-badge is a happy user of your DCObot. The issue is that there is no --signoff option in git for merge commits, which is a standard part of our workflow with feature branches. Here is a workflow where we currently get stuck:

(master)$ git checkout -b feature-branch
# make some changes
(feature-branch)$ git commit -sam 'Adding features'
# Changes have occurred on master so need to add them for easier merge
(feature-branch)$ git fetch
(feature-branch)$ git merge origin/master
# Save default commit message
(feature-branch)$ git push
# This now fails the DCObot check because the merge commit is not signed.

This alternative workflow works, but is obviously tedious:

# First 3 steps are the same
(feature-branch)$ git merge origin/master
# Save default commit message
(feature-branch)$ git commit --amend -s
# Commit message now has signoff line
(feature-branch)$ git push
# This now passes the DCObot check.

Or, I could manually add the Signoff line to the proposed git merge commit message, which would allow me to skip the --amend step.

Could you please add an option to the DCObot (and probably make it the default) not to check merge commits. I'm separately requesting that git add a -s option to git merge. Thanks.

Cc @david-a-wheeler @mkdolan @caniszczyk

It seems that there may be a situation in which this bot uses the user/email from a previously replaced commit. This seems to be happening over on envoyproxy/envoy#1743

Here's how we got in this state:

1. A commit was made and signed with user a
2. The commit was squashed and resigned with user b
3. The bot is still looking for user a, even though the commit is now signed with user b.

If one has a bot that's a regular user account what's the appropriate way to handle the DCO? Should the bot perform a signoff? Is there a way to detect and work around that?

We are currently expiring something strange on the DCO bot we've applied to our repo. Even though all commits are signed and the DCO bot seems to return successfully from its checks, the "merge" buttons stays blocked.
The PR in question: ros2/rmw_iceoryx#7

Any idea on what's happening here? Are we doing something wrong?

I am attaching a screenshot of this as well for future references (the PR might get merged soonish):

Because newcomers may not be so familiar with all the things. I can't find any way to find the DCO text. I know what DCO stands for and what is that bot, but someone may not know that, so... it makes friction.

Best would be the bot to comment on the text on failure. Or at least link to always available, for some reason currently I cannot load the https://developercertificate.org/ but it seems up.

Version 9.4.4 of nock was just published.

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I just got a red x from the DCO bot on this commit: git-for-windows/build-extra@1bafa00

However, this commit has a Signed-off-by: line, with my correct information...

Hi, It looks like the DCO check is in a weird state and not reporting. Can you help us out or point out if we are doing something wrong here? Thanks!
edgexfoundry/developer-scripts#98

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?

Dear DCO developers,

we use your bot to enforce Sign-Off lines by our users in our project. However, we often receive external contributions from users with few (or no) previous experience with Github and adding a Signed-Off-by message in all of their commits (by walking the tree and rewriting things) is something that is a bit complex to explain to newcomers.

Hence, our own solution was to ask users to just edit in the requested line into the pull request message and we accept this as being equivalent. However, DCO does not read the pull request text for these lines and hence we have to ignore its false positive for merging.

Can interpreting the pull request text be added in order to ease the process for git newcomers?

From @jsquyres in #17 (comment):

Is there a way to indicate why the DCO fails, perchance? I.e., not having a DCO is a pretty obvious fail. But if it fails because the DCO is present but incorrect, some kind of hint about what was incorrect would be awesome.

I think that's a great idea. I'll document what would need changed in case anyone is interested in taking this on:

1. Currently, the description of the failed status is hard coded. Modify the code that checks the dco (lib/dco.js) to return a reason for the failure (missing, author or email mismatch, etc).

2. Modify the code that calls this module in index.js:28 to save the failure. There are a few ways you could do this (throw an error, check if a string was returned, etc), but I'll leave that as an exercise for you.

3. Set description in index.js:30-33 to include the failing reason.

That should take care of it. Let me know if you have any questions.

I correctly signed off a commit with -s, but the bot complained because my address was not in all lowercase. Please compare case-insensitively.

envoyproxy/envoy#3021

Any idea what's up?

We've been seeing this issue a lot recently (I've personally seen it three times in the past week, and others on my team have brought it up as well). We create a new branch off our default develop branch, make a few changes that are DCO approved, and yet DCO bot fails saying commits by other developers are not signed off.

This PR is the latest example:

1. I made a new branch off our main branch
2. I made all my changes in three commits (all signed-off)
   reactioncommerce/reaction@16e3a71
   reactioncommerce/reaction@90b6757
   reactioncommerce/reaction@035b574
3. I made a PR, and am receiving a failed DCO check, from another developer with commits not in this PR: https://github.com/reactioncommerce/reaction/pull/5307/checks?check_run_id=166954847
   

UPDATE:
Another example just popped up: https://github.com/reactioncommerce/reaction/pull/5320/checks?check_run_id=167950629

It would be very nice to have a blacklist option instead of just an 'All repositories' or 'Whitelist' option.

In general we prefer to just enable the DCO check on all repositories, and not have to worry about it for any new repositories that may be created later. We do, however, have some organizations that have need of disabling the bot on some repos and this make management of the organization significantly more difficult as we now have to remember to enable the bot on new repos.

With a blacklist option then any repo that doesn't require DCO can be configured to not have it and all new repos by default would have it enabled unless we determine later that it's not needed.

hyperledger-archives/sawtooth-core#1002

#20 has a commit from a bot, which fails the DCO check. Any commit where the author name includes [bot] should be ignored.

In our organization we don't require verified commits by members, but we want to require signed-off commits by external contributors.

It would be great to add an option that allows non-verified commits by organization members. This would mean that the commit.verification.verified check in https://github.com/probot/dco/blob/master/lib/dco.js#L12 can be optionally disabled.

For example with the following config:

require:
  members: false
  members_verify: false

Or is there any specific reason why commits by organization members must be verified?

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.

See this PR failure...

https://github.com/zowe/zlc/pull/114/checks?check_run_id=137885176

It looks like while the user put in their normal Signed-off-by: in the commit, because they have a GitHub setting on which doesn't pass their real email as the committer ( https://help.github.com/en/articles/about-commit-email-addresses ) we get a mismatch.

Any ideas on what could be done to solve this?

Moving feedback from #8 (comment):

the main feature I would want would be "comment in the PR with instructions on how to add sign-off-by by default"

The fact that DCO requires the added line at each comment makes it very annoying to use and also prevents using the edit functionality in GitHub which auto opens a pull request. Once this pull request was created it will not have the signature on it and it will not be able to fix it.

Instead DCO should only require acceptance the first time when someone contributes, not on each request.

Sidenote, if someone knows a working alternative that does not annoy contributors on each request please let me know. I am looking for bot that would require only one time action on the first commit/PR.

See https://github.com/nexB/deltacode/pull/114/checks?check_run_id=83064273

Commit sha: 18ec9a6, Author: Shubham, Committer: Shubham; Expected "Shubham [email protected]", but got "Shubham [email protected]".

The expected and got are exactly the same, so what is the catch?

We'd like to use this Bot for OpenWrt but currently it seem to fail if multiple SoB lines are used and the first doesn't match the committer.

I'd suggest to change the current regex and use a while loop checking all found SoB lines.

I believe I've found a case where the DCO enforcement, when there is one unsigned commit, but it is not the last one.

To reproduce, I branch my repo, add a file and commit it unsigned:

git checkout -b dco-test
<Create bugdemo.txt>
git add bugdemo.txt
git commit -a -m "Unsigned commit"
git push --set-upstream origin dco-test

Then I made a change to the bugdemo.txt file and ran:

git commit -s -a -m "Signed commit"
git push

Going to the GitHub repo, I create a pull request, and the DCO bot promptly failed. The suggested commands to fix were:

git commit --amend --signoff
git push --force-with-lease origin dco-test

However, the DCO test continued to fail.

From a previous DCO failure report, I'd seen:

git rebase HEAD~2 --signoff
git push --force-with-lease origin dco-test

suggested. After running these, the DCO bot passed. However, I'd never have come up with the rebase if I hadn't seen it in an earlier error report.

I'm guessing this is because, although there was only one unsigned commit, it wasn't the last one - and git commit --amend only affects the tip of the current branch?

For reference:

> git --version
git version 2.20.1.windows.1

I'm afraid I don't have a Linux or Mac to hand for testing there

Steps to reproduce:

1. Create a repo with DCO bot enabled, branch protection on for the master branch with 'Require status checks to pass before merging' enabled and DCO status check required enabled before merged.
2. Add a new file to the repo with a DCO signoff. It will automatically force the user to create a new branch and pull request.
3. In that pull request, the DCO status check should be green or passed.
4. Choose to do a 'Squash and Merge' for the pull request ( see below ).

5. In the commit description, remove any Signed-Off by lines. Then click 'Confirm Squash and Merge'.

Expected behavior: Commit is blocked due to lack of DCO signoff
Actual behavior: Commit is successful, and the commit message has no DCO signoff

https://probot.github.io/apps/dco/ says:

By making a contribution to this project, I certify that:

1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

2. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

3. The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

4. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

The paragraphs are numbered with 1., 2., 3, and 4. but the refernce in 3. is (a), (b) or (c).

Sometimes PRs do not have a DCO, but you want to accept them anyway. There should be a note in the readme explaining how to override this check in specific PRs.