Skip to content

masterborn/cla-action

 
 

Repository files navigation

build

Handling CLAs with GitHub Action (Alpha)

Streamline your workflow and let this GitHub Action(a lite version of CLA Assistant) handle the legal side of contributions to a repository for you. CLA assistant enables contributors to sign CLAs from within a pull request. With this GitHub Action we get rid of the need for a centrally managed database by storing the contributor's signature data in a decentralized way - in the repository's file system

Features

  1. decentralized data storage
  2. fully integrated with github environment
  3. no UI required
  4. no need for permission/scope handling
  5. contributors can sign the CLA by just posting a Pull Request comment
  6. signatures will be stored in a file inside the repository plus optionally on the Ethereum Blockchain

Configure Contributor License Agreement within two minutes

1. Add the following Workflow File to your repository in this path.github/workflows/cla.yml

name: "CLA Assistant"
on:
  issue_comment:
    types: [created]
  pull_request:
    types: [opened,closed,synchronize]
    
jobs:
  CLAssistant:
    runs-on: ubuntu-latest
    steps:
      - name: "CLA Assistant"
        if: (github.event.comment.body == 'recheckcla' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request'
        # Alpha Release
        uses: cla-assistant/github-action@v1.3.0-alpha
        env: 
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with: 
          path-to-signatures: 'signatures/version1/cla.json'
          path-to-cla-document: 'https://github.com/ibakshay/test-action-workflow/blob/master/cla.md'
          # branch should not be protected
          branch: 'master'
          whitelist: user1,user2,bot*
          empty-commit-flag: false
          blockchain-storage-flag: false

2. Pull Request event triggers CLA Workflow

CLA action workflow will be triggered on all Pull Request opened, synchronize, closed.
When the CLA workflow is triggered on pull request closed event, it will lock the Pull Request conversation after the Pull Request merge so that the contributors cannot modify or delete the signatures (Pull Request comment) later. This feature is optional.

3. Signing the CLA

CLA workflow creates a comment on Pull Request asking contributors who have not signed CLA to sign and also fails the pull request status check with a failure. The contributors are requested to sign the CLA within the pull request by copy and pasting "I have read the CLA Document and I hereby sign the CLA" as a Pull Request comment like below. If the contributor has already signed the CLA, then the PR status will pass with success.
By default, this Action workflow will also create an empty commit with a message "@#contributorname# has signed the CLA" whenever a contributor signs the CLA.

Screenshot 2020-02-13 at 10 24 17


4. Signatures stored in a JSON file

After the contributor signed a CLA, the contributor's signature with metadata will be stored in a JSON file inside the repository like below screenshot and you can specify the custom path to this file with path-to-signatures input in the workflow.
The default path is path-to-signatures: 'signatures/version1/cla.json'

Screenshot 2020-01-07 at 16 13 43

5. Whitelisting users and bots

If a GitHub username is included in the whitelist, they will not be required to sign a CLA. You can make use of this feature If you don't want your colleagues working in the same team/organisation to sign a CLA. And also, since there's no way for bot users (such as Dependabot or Greenkeeper) to sign a CLA, you may want to whitelist them. You can do so by adding their names in a comma separated string to the whitelist input in the CLA workflow file(in this case dependabot-preview[bot],greenkeeper[bot]). You can also use wildcard symbol in case you want to whitelist all bot users something like bot*.

6. Signatures can be additionally stored on the Ethereum Blockchain

To make the whole process more fraud resistant we grant the option to additionally store the signatures on the Ethereum Blockchain. To use this feature just set the blockchain-storage-flag: true. A detailed description on integrating with the Ethereum Blockchain can be found here - special credits and thanks goes to @FabianRiewe.

Environmental Variables :

Name Requirement Description
GITHUB_TOKEN required Must be in the form of GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} , CLA Action uses this in-built GitHub token to make the API calls for interacting with GitHub. It is built into Github Actions and does not need to be manually specified in your secrets store. More Info
PERSISTANCE_GITHUB_TOKEN optional Must be included when persistance-repository is present - it should be PAT with repo access - suggested way is to create github machine-user with specific repository access only

Inputs Description :

Name Requirement Description
path-to-cla-document required provide full URL https://<clafile> to the Contributor License Agreement (CLA) to which the Contributor can read before signing the CLA. It can be a file inside the repository or it can be a gist
path-to-signatures optional Path to the JSON file where all the signatures of the contributors will be stored inside the repository. Default path is "./signatures/cla.json".
branch optional Branch in which all the signatures of the contributors will be stored and Default branch is master
empty-commit-flag optional provide the boolean true or false so that GitHub Actions will add empty commit whenever user signs the CLA. Default is true
whitelist optional You can specify users and bots to be whitelisted. For example user1,user2,bot*
blockchain-storage-flag optional provide the boolean true or false to optionally store the Contributor's signature data in the Ethereum blockchain. Default is false
persistance-repository optional provide name of repository in organization scope to which contributors should be persisted into

This action won't work for Pull Request coming from the forks as the GitHub Action Token does not have write access for the forks, However, the GitHub team assured in one of the discussion that they will ship this feature to enable read/write access for the PRs coming from the forks.

License

Contributor License Agreement assistant

Copyright (c) 2020 SAP SE or an SAP affiliate company. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Credits

❤️ from the GitHub team @SAP

Packages

No packages published

Languages

  • TypeScript 99.3%
  • JavaScript 0.7%