Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DCO (signed-off-by) in commits via web ui #50

Closed
caniszczyk opened this issue Mar 31, 2017 · 78 comments
Closed

DCO (signed-off-by) in commits via web ui #50

caniszczyk opened this issue Mar 31, 2017 · 78 comments
Labels

Comments

@caniszczyk
Copy link
Member

When you use the web ui in GitHub, there's no option to do the equivalent of (git commit -s) which is required as part of adhering to the DCO. The GitHub web ui should support this workflow :)

@bkeepers
Copy link

This is the biggest thing that can't be built into an integration.

One question I have about this: The DCO requires sign-off on each commit, so this would have to be a checkbox wherever commits are made (merge button, editor) instead of a user config that says "Add sign-off on all my commits"?

xref dcoapp/app#8 #48

@jparise
Copy link
Member

jparise commented Mar 31, 2017

Would this also imply some level of support for #32?

@caniszczyk
Copy link
Member Author

@bkeepers any chance in hell in this one happening :)?

More LF related projects are using DCO on GitHub (thanks for prbot) and not being able to edit things via the GH UI is pain :) #50

@mattklein123
Copy link

+1 please!

@craigez
Copy link

craigez commented Sep 15, 2017

I just ran into a related issue the other day, the probot app only works on PRs and not direct pushes. If you want pushes and PRs to have the DCO enforced it looks like you need a hook as well :(. I need to check if Org level hooks are available/enforceable.

@bkeepers
Copy link

@bkeepers any chance in hell in this one happening :)?

I don't know.

In general, my advice would be to try to standardize practices around the DCO as much as possible, and clearly document all the best practices and edge cases.

I could be a really easy feature to add (checkbox on the commit comment box?), but it also brings up a bunch of other questions: Can it be automatic, or does the user have to take an action every time to communicate their intent? Is it visible on every repository, or is there a repository setting that turns it on? Should there be a setting to require it on all commits? What about scenarios where it's not actually required, like bots dcoapp/app#21?.

Unless I'm misunderstanding something, you can manually include the Signed-off-by line in the commit comment box, right? I know it's annoying, but I just want to make sure it's possible first. You could use a browser extension to make that quick and easy.

dco

probot app only works on PRs and not direct pushes

It is currently recommended to set DCO as a required status to protect master. Feel free to open an issue on probot/dco if you'd like to see it do something different.

@mattklein123
Copy link

mattklein123 commented Sep 23, 2017

I want to mention #53 (which I just opened) in the context of this issue. I think it would be really awesome if we could block force pushes to PRs. However, if we do that, making sure that people put DCO onto every commit is super important, otherwise it will destroy a PR where someone forgets. IMO DCO will need to get built directly into GH as a first class thing in order to make the workflow not painful (it's actually pretty painful today).

@bkeepers
Copy link

IMO DCO will need to get built directly into GH as a first class thing in order to make the workflow not painful (it's actually pretty painful today).

I'd love to hear what the ideal workflow would be for you. Any examples of tools that do it really well?

@mattklein123
Copy link

I'd love to hear what the ideal workflow would be for you. Any examples of tools that do it really well?

I don't have any examples, as I've just been using DCO now for about a week. But I can tell you my current thoughts based on what I've seen:

Right now the flow is very painful as every commit has to manually have the DCO added. If someone forgets on a single commit, the DCO bot fails, and the only possible resolution for the user is to manually rebase the PR to fix the commit message (which is asking a lot) or to squash and force push with DCO. Either way the review history gets messed up badly (see #53). We can have documentation and also a client side commit hook that we ask people to install, but this is high friction for new/infrequent contributors and people forget. As a reviewer this is my biggest pain point right now.

My optimal baseline flow would look like:

In a perfect world we would also get the ability to:

  • Have DCO be part of the web commit UI where it blocks me from committing depending on project permissions.
  • Setup "auto DCO" for my account so GH would just auto sign off all my commits for me for a particular project, whether via web UI or manual push.

I realize the previous two points require a lot of thinking, so would be very happy to just nail the baseline flow first.

@htuch
Copy link

htuch commented Sep 25, 2017

+1 on server-side commit hook enforcing DCO (at least for Envoy). This seems a simple change to get us most of the pain out of the way.

@jmertic
Copy link

jmertic commented Aug 21, 2018

I'd be fine with an extra checkbox below the commit message that lets you do the signoff.

@leecalcote
Copy link

I want to enable probot's dco enforcement, but the lack of web ui support will likely cut off a high number of quick edits from communities engaged in my projects.

To me, the ideal functionality here is a GitHub account user preference (configurable per repo or per org) for auto-signing signing commits whether via web UI or manual push (+1 to @mattklein123 and @htuch's suggestion). The lack of web UI support here certainly turns away anyone inclined to quickly contribute markdown edits on projects. This inhibits user contribution to documentation and other non-code artifacts (key for much of @caniszczyk's stewarding and organizing within the CNCF).

@mkdolan
Copy link

mkdolan commented Aug 7, 2019

Has there been any progress on this @bkeepers ? Is there any way we can help move it forward?

@caniszczyk
Copy link
Member Author

@jeffmcaffer may know but right now, you can just manually add the "Signed-off-by: XYZ" as part of the pull request and it works fine

@jplevyak
Copy link

+1

Just got burned by this.

@ryjones
Copy link

ryjones commented Sep 17, 2019

This just burned us, as well, on Hyperledger.

@bdougie
Copy link

bdougie commented Sep 25, 2019

Would love feedback if this helps: I wrote a GitHub Action to edit commits to a pull request with a signature.

To try it out add the below to your .github/workflows/sign-off.yml in a PR. I have it limited to markdown files, but you can remove that path requirement in the YAML if needed.

https://gist.github.com/bdougie/c31ea9f59d9d049a732a046be017eb28

update: I see there is a DCO bot and this action doesn't work well with this. Some tinkering is still needed.

@brianjmurrell
Copy link

@bdougie Doesn't your concept invalidate the point of the SoB? AFAIU, the SoB is supposed to be the person submitting the patch making personal attestations to the validity/origin and right to submit the patch.

As such it seems it needs to be submitted with the patch by the author, not just added at commit time by the SCM server as the SCM doesn't know the origin of the patch and whether it's origin is compatible with the project. It could be copyrighted material after-all and in such a case, the submitter didn't sign it off, GitHub (who really can't/shouldn't) did.

@amye
Copy link

amye commented Dec 20, 2019

Just burned on this one, even with a Signed-off-by in the commit.
If you have your email address set to private, it wants the 'noreply' email, which is obviously a thing you completely remember every time.

@ryjones
Copy link

ryjones commented Dec 20, 2019

I know @dhuseby is working on DID:GIT to try to obviate some of this

@stormi
Copy link

stormi commented May 10, 2022

So, I like that we can have DCO added automatically to commits made with the web UI. Now I don't know how to handle users who hide their e-mail address and real name, as this goes against the principles of DCO:

Signed-off-by: loginname loginname@users.noreply.github.com.

Should we envision an option that would allow an organisation to enforce the use of an actual e-mail address?

@ryjones
Copy link

ryjones commented May 10, 2022

@stormi

Should we envision an option that would allow an organisation to enforce the use of an actual e-mail address?

please and thank you

@ryjones
Copy link

ryjones commented May 10, 2022

@davidstaheli please enable for these orgs (you should be able to verify my ownership):

@davidstaheli
Copy link

Apologies for the long delay.

  • @ryjones, the feature is now enabled for theheraldproject, thecardeaproject, openidl-org, and lfph.
  • @stormi, thank you for that great point. We'll think through this, including what the user experience should be if real names and email addresses are enforced but the committer has not yet set them up. I hope to have something to share here soon.
  • @scottrigby, the feature is now enabled for open-gitops, fluxcd, and helm. Nice job on the browser extension! It must be helping a lot of people. I appreciate your kind acceptance of this feature being built into GitHub and don't want to diminish the importance of what you've built. We on the GitHub Repositories team admire what you've done.

@qnetter
Copy link

qnetter commented May 19, 2022

How about for goharbor?

@jpadams
Copy link

jpadams commented May 23, 2022

@davidstaheli congrats on shipping this feature! 🚢 🎉 I was a supporter when I was at GitHub. We'd love to have the option to trial it at https://github.com/dagger where we use DCO for our open source contribs. Great work team!

@ghost
Copy link

ghost commented May 24, 2022

@davidstaheli We're currently evaluating the use of a DCO on two organizations. Would you be able the add the preview feature to:

https://github.com/containerssh
https://github.com/chaos-kubox

Thanks a bunch for working on this!

@stormi
Copy link

stormi commented May 25, 2022

@davidstaheli This is probably already in the pipe, but one will need to be able to choose which email to sign off commit suggestions with, in PRs. Currently I don't think you can:
image

@caniszczyk
Copy link
Member Author

@davidstaheli can you add github.com/cncf to this list too

@sambhav
Copy link

sambhav commented Jun 6, 2022

@davidstaheli https://github.com/buildpacks and https://github.com/kyverno would also greatly benefit from an early preview of this feature. It would be great if you could enable it for these organizations as well :)

This is an game-changing feature for almost all of the CNCF projects! (most of them require DCO sign-off)

@ashleywolf
Copy link
Member

ashleywolf commented Jun 6, 2022

@caniszczyk

@davidstaheli can you add github.com/cncf to this list too

Added

@caniszczyk
Copy link
Member Author

caniszczyk commented Jun 6, 2022 via email

@ashleywolf
Copy link
Member

@davidstaheli https://github.com/buildpacks and https://github.com/kyverno would also greatly benefit from an early preview of this feature. It would be great if you could enable it for these organizations as well :)

This is an game-changing feature for almost all of the CNCF projects! (most of them require DCO sign-off)

@samj1912 added 👍

@ryjones
Copy link

ryjones commented Jun 6, 2022

Thank you, Ashley. This is great!

@davidstaheli
Copy link

So sorry for the big delay while I've been away for 2 weeks. Thanks for helping with these, @ashleywolf! I'll enable this for any that remain on Tuesday, June 7. We also plan to ship the feature publicly - so it will be enabled for everyone - on Wednesday, June 8.

@davidstaheli
Copy link

The DCO signoff feature is newly available to the following organizations. Thanks for your patience! See directions below for enabling the feature. It should release publicly (to everyone) tomorrow, Wednesday, June 8.

  • goharbor (@qnetter)
  • dagger (@jpadams, hello! You'll always be a Hubber! 😀)
  • containerssh, chaos-kubox (@sanjacodes)

How to enable required signoffs for an organization

Organization owners can configure an organization-level setting to require sign off on commits made through the web interface. To do so, click Settings in an organization that you are an owner of. Next, in the navigation under Code, planning, and automation, select Repository and then Repository defaults. Finally, under Commit signoff choose All repositories to require sign off on web-based commits in all repositories in the organization, as shown below. Alternatively, select No policy to disable the setting so that sign off will not be required unless enabled at the repository level.

GitHub's organization-level setting for requiring sign off on commits made in the web interface

How to enable required signoffs for a repository

Repository admins can toggle a similar repository-level setting. To do so, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Require contributors to sign off on web-based commits as shown below. This setting will be overridden by the organization-level setting unless the organization has No policy selected.

GitHub's repository-level setting for requiring sign off on commits made in the web interface

@caniszczyk
Copy link
Member Author

caniszczyk commented Jun 7, 2022 via email

@ghost
Copy link

ghost commented Jun 7, 2022

Thanks a bunch for all your work! 🙏🏻

@gbartolini
Copy link

Fantastico! Thanks!

@caniszczyk
Copy link
Member Author

@davidstaheli will there be a github blog post or changelog entry to link too?

@davidstaheli
Copy link

Hi, @caniszczyk! Yes, I'll publish an extra-long changelog right when the feature goes live for everyone. It should appear at the URL below. And I'll do my best to post an update here when it happens.

@caniszczyk
Copy link
Member Author

@davidstaheli
Copy link

🎊

Yes, the feature is now live! Thanks so much for everyone's suggestions and encouragement with this! We'd still like to make improvements and would love to hear ongoing suggestions that you have. A good place to leave feedback is in GitHub's public feedback discussions (General category) or email me at: my GitHub username + "@github.com". Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests