opensearch-project / project-meta

Tools to make it easy to manage processes across the opensearch-project org.
https://opensearch.org/
Apache License 2.0
4 stars 17 forks source link

Required DCO verification on pull requests #17

Closed peternied closed 2 years ago

peternied commented 2 years ago

Recently DCO check was added to the .github template for OpenSearch-Project, this should be rolled out into all of the existing repositories to ensure that DCO checks are done on any incoming pull requests.

peternied commented 2 years ago

To fan this issue out to all repos, this is the command:

meta exec "gh issue create --label enhancement --title 'Ensure DCO Check' --body-file ../issue.md"

issue.md:

A Developer Certificate of Origin is required on commits in the OpenSearch-Project.

See doc.yml for an example workflow. Ensure CONTRIBUTING.md to has a section on the DCO per the project template.

  • [ ] DCO Check Workflow
  • [ ] CONTRIBUTING.md DCO Section

@dblock mind reviewing this before I pull the trigger?

dblock commented 2 years ago

You'll want the child issue linked to this one (or another parent) that can be updated easily in case instructions need to evolve, and be a little more prescriptive scoped for the repo in which the issue is opened. Plus DCO.yml should not be DOC.yml ;)

Coming from https://github.com/opensearch-project/project-meta/issues/17.

A Developer Certificate ... (I would drop not all repositories ...).

See [dco.yml](https://github.com/opensearch-project/.github/blob/main/workflow/dco.yml) for an example. Ensure that CONTRIBUTING has a section ...

- [ ] ... 

When you run meta it will execute in a subdirectory of the project, so you'll need to make issue.md and reference it as ../issue.md.

vchrombie commented 2 years ago

coming from https://github.com/opensearch-project/opensearch-py/issues/80#issuecomment-931543356

in short, the dco bot can be configured at the organization level and it doesn't need any github action workflows.

I just wanted to comment about the other options available. Please feel free to proceed with whatever option the organisation maintainers prefer. Thanks.

peternied commented 2 years ago

Initially we considered using that DCO bot and choose not to due to its requirement to access private repositories.

This option seems like the best path forward to stop the manually inspection ever commit in a pull requests

dbbaughe commented 2 years ago

@peternied Instead of having everyone go and create duplicate github workflows across all the repositories, do you want to create workflow template in the .github repository and then all repos can reuse that workflow without having to duplicate?

https://docs.github.com/en/actions/learn-github-actions/creating-workflow-templates https://docs.github.com/en/actions/learn-github-actions/reusing-workflows

This probably applies to quite a few different workflows we have, we can take everything common in the different repositories, define them in a single place (.github repo) and reuse so the actual workflow definition if needed to be changed can be done in one place.

peternied commented 2 years ago

@dbbaughe Looking atcalling-a-reusable-workflow would look something like this with already checked in version of this workflow:

jobs:
  dco-check:
    uses: opensearch-project/.github/workflows/doc.yml@main

Could you try that out and see if we should change the instructions on the issues?

dbbaughe commented 2 years ago

@peternied Based on the creating-workflow-templates part it seems the reusable templates must be in a directory called workflow-templates along w/ some json properties file before they can be used.

peternied commented 2 years ago

I'll drill in more next week, great suggestion

peternied commented 2 years ago

@dbbaughe I've attempted to follow the instructions with my own organization, but haven't been able to get it to work. If you can get it to work I would be happy to update the instructions on all the issues.

In either case, each team will still need to create a workflow and update its CONTRIBUTING.md