dcoapp / app Goto Github PK
View Code? Open in Web Editor NEWGitHub App that enforces the Developer Certificate of Origin (DCO) on Pull Requests
Home Page: https://github.com/apps/dco
License: ISC License
GitHub App that enforces the Developer Certificate of Origin (DCO) on Pull Requests
Home Page: https://github.com/apps/dco
License: ISC License
Any idea what's up?
🚨 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.
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...
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.
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?
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?
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?
Steps to reproduce:
Expected behavior: Commit is blocked due to lack of DCO signoff
Actual behavior: Commit is successful, and the commit message has no DCO signoff
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.
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)
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?
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
I correctly signed off a commit with -s
, but the bot complained because my address was not in all lowercase. Please compare case-insensitively.
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?
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?
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?
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"
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:
user a
user b
user a
, even though the commit is now signed with user b
.Branch | Build failing 🚨 |
---|---|
Dependency | nock |
Current Version | 9.4.3 |
Type | devDependency |
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.
The new version differs by 3 commits.
907be86
fix(#1076): allowUnmocked: true + host regex (#1179)
8f0912a
docs: Add CHANGELOG file pointing to GitHub releases
15a472f
build(#1169): remove glob and istanbul
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
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).
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?
(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.
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.
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?
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
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'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:
UPDATE:
Another example just popped up: https://github.com/reactioncommerce/reaction/pull/5320/checks?check_run_id=167950629
#20 has a commit from a bot, which fails the DCO check. Any commit where the author name includes [bot]
should be ignored.
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.
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:
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).
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.
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.
7.2.0
to 7.3.0
.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.
probot simulate
in favor of probot receive
(#726, #730) @gimenete, @hiimbex@octokit/rest
(#721, #732 - @hiimbex)The new version differs by 17 commits.
5dc37f6
7.3.0
76b5edd
Update docs for manually receiving events (#730)
ad06bd5
Deprecate probot simulate
in favor of probot receive
(#726)
aef4d72
Wrap pem in quotes to make Glitch happy (#737)
8964e7c
Update development.md (#735)
6b5e9a2
chore(package): update @octokit/rest to version 15.13.1 (#732)
914d968
Update standard-markdown to the latest version 🚀and lint docs
00f0e19
chore(package): update typedoc to version 0.13.0 (#731)
0036fee
chore(package): update commander to version 2.19.0 (#729)
f657a97
Create README.pt-br.md (#711)
7cb1167
fix(package): update dotenv to version 6.1.0 (#724)
1f88f43
Update octokit rest (#721)
3bee037
remove manual base64 encoding/decoding of private key (#717)
8663f1b
chore(test): convert app/default test to TypeScript (#703)
18821db
chore(test): convert Sentry test to TypeScript (#702)
There are 17 commits in total.
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
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
?
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 :)
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.
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:
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.
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.
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"
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.
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:
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):
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.
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.
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?
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.