dco-check

Simple DCO check script to be used in any CI.

Motivation

Many open-source projects require the use of a Signed-off-by: line in every commit message. This is to certify that a contributor has the right to submit their code according to the Developer Certificate of Origin (DCO). However, to my knowledge, there is no automated check that can run on any CI platform (or most platforms). Some platforms simply do not possess such a feature.

This was inspired by the DCO GitHub App.

How to get & use

There are a few options:

1. Using the package from PyPI

   $ pip install dco-check
   $ dco-check
   

2. Using the Docker image (christophebedard/dco-check) with your CI (see examples)

   $ dco-check
   

3. Downloading the script and running it (you can replace master with a specific version)
   This is enabled by the fact that dco-check is a single Python file without any third-party dependencies.

   $ wget https://raw.githubusercontent.com/christophebedard/dco-check/master/dco_check/dco_check.py
   $ python3 dco_check.py
   

It exits with 0 if all checked commits have been signed-off. Otherwise, it exits with a non-zero number.

Run with --help for more information and options, including:

• ignoring merge commits
• default branch
• default remote
• quiet mode
• verbose mode

Those options can alternatively be set through environment variables (see --help), but commandline arguments always have precedence over environment variables.

How it works

dco-check focuses on two use-cases:

1. Commits part of a feature branch, i.e. a proposed change (pull request or merge request)
2. Commits on the default branch, e.g. master, or more specifically the new commits pushed to the default branch

The first use-case is easy to cover given a normal git repository. We can simply use git merge-base --fork-point $DEFAULT_BRANCH to get the list of commits on a specific feature branch off of the default branch. Some CIs provide even more information, such as the target branch of the change, which is useful if we don't expect to always target the default branch. Then we can just check every commit using git log and make sure it is signed-off by the author.

The second use-case isn't really possible with simple git repositories, because they do not contain the necessary information (AFAIK). Fortunately, some CIs do provide this information.

Furthermore, by default, some CI platforms only clone git repositories up to a specific depth, i.e. you only get a partial commit history. This depth can sometimes be 1 for some CIs, i.e. a shallow clone. For those cases, it is usually possible to prevent shallow cloning by setting the right parameter(s) in the job configuration. However, since one of the goals of dco-check is to be as easy to use as possible, it tries not to rely on that.

This is why dco-check detects the current CI platform and uses whatever information that platform can provide. Otherwise, it falls back on a default generic implementation which uses simple git commands. In those cases, the CLI options allow users to provide a lot of the missing information.

CI support

Below is a summary of the supported CIs along with their known behaviours.

Example CI configurations

Here are some example CI configurations.

GitHub

# .github/workflows/dco.yml
name: DCO
on:
  pull_request:
  push:
    branches:
      - master
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up Python 3.x
      uses: actions/setup-python@v1
      with:
        python-version: '3.x'
    - name: Check DCO
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        pip3 install -U dco-check
        dco-check

GitLab

# .gitlab-ci.yml
variables:
  DOCKER_DRIVER: overlay2
dco:
  image: christophebedard/dco-check:latest
  rules:
    - if: $CI_MERGE_REQUEST_ID
    - if: $CI_EXTERNAL_PULL_REQUEST_IID
    - if: $CI_COMMIT_BRANCH == 'master'
  script:
    - pip3 install -U dco-check  # optional
    - dco-check

Python version support

Python 3.6+ is required because of the use of f-strings. However, it shouldn't be too hard to remove them to support older versions of Python 3, if there is a demand for it, or if such a change is contributed to dco-check.

Contributing

See CONTRIBUTING.md.