README.md

Note

This is the manaflow-ai/cla-github-action fork of cla-assistant/github-action, which was archived on 2026-03-23. Manaflow maintains this fork for its public repositories. It is not a general-purpose successor to the archived project.

Divergences from upstream are documented in CHANGELOG.md. Highlights: Node 24 runtime, current @actions/github, TypeScript 6 with full strict mode, an in-process and subprocess test harness, GitHub-resolved commit identities, strict electronic-signature matching, authenticated opener-ID exemptions, live Pull Request validation, and an opener identity guard.

Handling CLAs and DCOs via GitHub Action

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 GitHub action enables contributors to sign CLAs from within a pull request. With this GitHub Action we could get rid of the need for a centrally managed database by storing the contributor's signature data in a decentralized way - in the same repository's file system or in a remote repository which can be even a private repository.

The sample below is an advisory signer workflow. It records signatures and reports the CLA result, but an issue_comment run cannot replace a failed pull_request_target check on the Pull Request head. If branch protection requires this check, add a separate trusted exact-head worker that accepts only this action's signature_recorded=true output, authenticates the commenter, and binds the current Pull Request number, head SHA, base branch, and workflow before calling the Actions rerun API. Keep actions: write out of this signer job. Without that worker, leave the CLA check advisory.

Features

1. decentralized data storage
2. fully integrated within github environment
3. no User Interface is required
4. contributors can sign the CLA or DCO by just posting a Pull Request comment
5. signatures will be stored in a file inside the repository or in a remote repository
6. signatures can also be stored inside a private repository
7. versioning of signatures

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 v2"
on:
  issue_comment:
    types: [created]
  pull_request_target:
    branches: [main]
    types: [opened,edited,closed,reopened,synchronize,ready_for_review]

permissions: {}

jobs:
  CLACommentGate:
    if: >-
      (github.event_name == 'pull_request_target' &&
      (github.event.action == 'opened' || github.event.action == 'edited' ||
      github.event.action == 'closed' || github.event.action == 'reopened' ||
      github.event.action == 'synchronize' || github.event.action == 'ready_for_review')) ||
      (github.event_name == 'issue_comment' &&
      github.event.action == 'created' &&
      github.event.comment.user.type == 'User' &&
      github.event.comment.user.id > 0 &&
      github.event.issue.state == 'open' && github.event.issue.pull_request &&
      (github.event.comment.body == 'recheck' ||
      github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA'))
    name: "CLA Comment Gate"
    runs-on: ubuntu-latest
    timeout-minutes: 2
    permissions: {}
    concurrency:
      group: cla-admission-${{ github.repository }}-${{ github.event_name }}-${{ github.event.issue.number || github.event.pull_request.number }}
      cancel-in-progress: false
    steps:
      - name: "Validate exact CLA comment"
        if: github.event_name == 'issue_comment'
        shell: bash
        env:
          COMMENT_BODY: ${{ github.event.comment.body }}
          SIGN_PHRASE: I have read the CLA Document and I hereby sign the CLA
        run: |
          if [[ "$COMMENT_BODY" != "recheck" && "$COMMENT_BODY" != "$SIGN_PHRASE" ]]; then
            echo "::error::Comment must match the recheck command or signing declaration exactly."
            exit 1
          fi

  CLAAssistant:
    name: "CLA Assistant v2"
    needs: CLACommentGate
    if: always() && needs.CLACommentGate.result == 'success'
    outputs:
      # A trusted same-workflow rerun job may consume this only after it also
      # binds the current Pull Request, head SHA, base branch, and workflow.
      signature_recorded: ${{ steps.cla_action.outputs.signature_recorded }}
      cla_passed: ${{ steps.cla_action.outputs.cla_passed }}
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: write # this can be read if signatures are in a remote repository
      issues: write
      pull-requests: write
      # No statuses permission is needed. The action fails or succeeds this
      # GitHub Actions job through @actions/core and never calls the commit
      # status or check-run APIs.
    # Advisory signer only. A separate trusted exact-head worker is required
    # when this check is required by branch protection. Serialize signer runs
    # for one Pull Request. A separate lock job uses the
    # distinct cla-lock group documented below and validates the live PR too.
    concurrency:
      group: cla-signatures-${{ github.repository }}-${{ github.event.pull_request.number || github.event.issue.number }}
      # Keep cancellation disabled. GitHub retains one running and one
      # pending run for this group. CLACommentGate rejects case variants and
      # arbitrary comments before this privileged queue.
      cancel-in-progress: false
    steps:
      - name: "CLA Assistant v2"
        id: cla_action
        # Pin to a full 40-character commit SHA, not a tag — see "Pinning by commit SHA" below.
        uses: manaflow-ai/cla-github-action@fc608ba7106e7029d981d487d7bad28a64325956
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Only set this token for a remote signature repository. Prefer a
          # fine-grained token limited to that repository with Contents read
          # and write access.
          # PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        with:
          path-to-signatures: 'signatures/version1/cla.json'
          path-to-document: '<REPLACE_WITH_CLA_URL>' # Required absolute HTTPS URL
          # Initialize this branch, then restrict writes to trusted CLA automation.
          branch: 'cla-signatures'
          required-base-ref: 'main'
          require-opener-as-author: 'true'
          # Add allowlist-ids only for a documented automated PR opener, using
          # that opener's numeric GitHub account ID. Never allowlist a name or
          # email from commit metadata.

         # the followings are the optional inputs - If the optional inputs are not given, then default values will be taken
          #remote-organization-name: enter the remote organization name where the signatures should be stored (Default is storing the signatures in the same repository)
          #remote-repository-name: enter the  remote repository name where the signatures should be stored (Default is storing the signatures in the same repository)
          #create-file-commit-message: 'For example: Creating file for storing CLA Signatures'
          #signed-commit-message: 'For example: $contributorName has signed the CLA in $owner/$repo#$pullRequestNo'
          #custom-notsigned-prcomment: 'pull request comment with Introductory message to ask new contributors to sign'
          #custom-pr-sign-comment: 'The signature to be committed in order to sign the CLA'
          # If set, replace the default declaration in the job `if` guard with this exact text.
          #custom-allsigned-prcomment: 'pull request comment when all contributors has signed, defaults to **CLA Assistant Lite bot** All Contributors have signed the CLA.'
          #lock-pullrequest-aftermerge: false - if you don't want this bot to automatically lock the pull request after merging (default - true)
          #use-dco-flag: true - If you are using DCO instead of CLA
          #require-opener-as-author: false - if your workflow involves submitters legitimately opening PRs containing only commits authored by others (cherry-picks, release engineering). Default is true.

Replace <REPLACE_WITH_CLA_URL> with the non-empty absolute HTTPS URL of the CLA or DCO. The action rejects an empty, relative, or non-HTTPS value before it makes a GitHub write.

The CLACommentGate job admits the listed pull_request_target lifecycle actions and filtered new issue_comment events from a GitHub User with a positive account ID. It has no write permission. Its bounded concurrency group separates each repository, event class, and Pull Request. Its if guard filters most comments, but GitHub expression equality is case-insensitive. The shell step runs for comments and is the authority for the required case-sensitive comparison. The advisory CLAAssistant signer requires gate success for both event classes and enters its own signer concurrency group only after the gate succeeds. A required-check deployment also needs the separate trusted exact-head worker described above. If you set custom-pr-sign-comment, replace the default declaration in the gate if guard and SIGN_PHRASE with that custom text. If you set use-dco-flag: true, replace both with I have read the DCO Document and I hereby sign the DCO. Keep recheck as the separate exact alternative. Do not broaden the signer job to run for every issue comment.

GitHub workflow event admission cannot compare a comment body case-sensitively. The unprivileged gate must start a runner to reject a case variant. GitHub keeps only one pending run in each concurrency group, so a same-PR case variant can replace one pending gate run before the exact shell check. It cannot enter the privileged signer queue. The contributor must post the exact comment again when this occurs. A high-volume public repository needs a trusted webhook or GitHub App classifier, or an external rate limit, when this fairness or runner-resource denial-of-service risk is material.

The shell step and the action compare the raw comment body and do not trim whitespace. Contributors must post the declaration with no leading or trailing whitespace for it to count as an electronic signature. Keep the pull_request_target.branches filter and required-base-ref input set to the same protected branch. The event filter avoids unnecessary runs; the action input revalidates the live base branch before a write or lock.

This version accepts signing and recheck only on newly created comments. A declaration comment must have matching GitHub creation and update timestamps. A comment edited into the declaration stays invalid on a later recheck. The workflow does not trigger on issue_comment edited events. The pull_request_target edited and ready_for_review lifecycle events are admitted for the action's live validation. Do not add an issue-comment edited trigger unless a later action version validates the edited event and the exact updated declaration at runtime.

The sample lets any authenticated human Pull Request commenter use recheck only to refresh this action. Do not reuse that condition for a job with actions: write or another privileged queue operation. A separate rerun worker must authenticate the commenter, then bind the request to the current Pull Request number, head SHA, workflow file, and base branch. The signer sample remains advisory until that worker is installed.

The action exposes signature_recorded=true only after it persists a new signature. The sample gives the action step an ID and publishes this as needs.CLAAssistant.outputs.signature_recorded for a trusted later job in the same workflow. That rerun job may use the output only after it binds the exact failed check to the current Pull Request number, head SHA, base branch, and workflow. A separate workflow cannot consume a job output directly and needs an authenticated handoff. Do not authorize a rerun from an arbitrary signing comment when this output is false.

The action exposes cla_passed=true only after the write-capable signer has confirmed that every required contributor is signed and successfully applied the final all-signed CLA bot comment. It remains false for signer-preflight, unsigned, closed, and error runs. signature_recorded=true only means that this run persisted one new signature, so it can be true while cla_passed remains false for another unsigned contributor. cla_passed is a per-run result, not durable authorization; consumers must also require the writer job to succeed.

For a least-privilege admission gate, run the action with mode: signer-preflight in a separate job that has only contents: read, pull-requests: read, and issues: read. The GraphQL commit identity connection requires contents: read in private repositories. The mode re-fetches the live Pull Request, resolves the current primary author identities through the same bounded GraphQL query as the signer, and verifies the event comment against the canonical unedited comment. It sets signer_authorized=true only for a matching account ID and emits the validated head and base commits as head_sha and base_sha. It also emits comment_id, comment_created_at, and comment_author_id for the exact declaration it authenticated. Pass those three outputs to the writer's expected-comment-id, expected-comment-created-at, and expected-comment-author-id inputs. The writer re-fetches that exact comment before every ledger or Pull Request comment write and accepts no replacement declaration. Inspect signer_decision to distinguish authorized, an exact declaration accepted by identity policy, from unauthorized, an exact declaration rejected by identity policy, and error, a validation or GitHub request failure. The action fails the job for both non-authorized decisions. Run the write-capable signer only when signer_authorized is 'true'. Pass both SHA outputs to its expected-head-sha and expected-base-sha inputs. The writer compares all five values with the live Pull Request and comment before any ledger or comment write and on every later revalidation, so a force-push, base-branch advance, edited comment, or replacement comment fails closed. The write-capable signer must still perform its own live validation after the gate because preflight outputs are ephemeral admission results, not durable authorization tokens.

The action publishes an all-signed bot comment only after it revalidates the signing comments and persists any new signatures. If a signer edits or deletes the declaration during the run, the ledger and the previous trusted bot status stay unchanged.

If the signature ledger does not exist, the first run creates an empty ledger and leaves any declaration from that run pending. Post a new recheck comment after the ledger exists. The action then validates and records the prior exact declaration before it publishes all-signed status.

If two Pull Requests try to create the first ledger together, the losing run makes at most three safe reads. It continues only when a read confirms a valid ledger. Otherwise it fails closed. An unsigned contributor stays pending, and a valid signing declaration can reach all-signed status only after the confirmed ledger records it.

The ledger is shared by all Pull Requests. Each signer workflow can use a per-Pull Request concurrency group, while the action uses bounded optimistic locking for cross-Pull Request writes. On a contents conflict it re-reads the ledger, merges the new signature, revalidates the live Pull Request and signing comment, and retries at most three writes. Persistent contention or an invalid read fails closed, so a contributor must post recheck after the queue is available. Extreme concurrent signing can therefore delay availability, but it cannot cause an unbounded runner loop or discard an already committed signature.

The action re-fetches accepted signing comments immediately before a ledger write. It also re-fetches the authenticated bot marker immediately before each create or update and rejects a stale plan when its presence, ID, identity, body, or timestamps changed. It rejects a comment that was edited, deleted, or moved to another identity during the run. GitHub does not provide one transaction or compare-and-swap operation for comments and repository contents, so a short GET-to-write race remains after the final check. A failed or stale run stays fail-closed and can be retriggered with recheck.

Important

Pinning by commit SHA

The uses: line above references this action by its full 40-character commit SHA, not by a version tag like @v3.0.0. This is intentional and strongly recommended for all third-party GitHub Actions.

Git tags are mutable: a maintainer (or a compromised maintainer account) can retarget v3.0.0 to a different commit at any time, silently changing what code runs in your CI with full access to GITHUB_TOKEN. A commit SHA is content-addressed and immutable — once you have audited the code at that SHA, it cannot change underneath you. See Why you should pin GitHub Actions by commit hash and GitHub's own security hardening guide for the full rationale.

To find the SHA to pin to:

# Latest commit on master:
git ls-remote https://github.com/manaflow-ai/cla-github-action.git refs/heads/master

Or browse to the releases page or commits page, pick a commit, and copy the full SHA. After pinning, add the human-readable reference as a trailing comment so future readers know what they're looking at:

uses: manaflow-ai/cla-github-action@91ce707cb678fe377c6788ecbf8470fa6205a969

Use a protected merged commit or release for enforcement. Do not pin an unmerged feature branch or Pull Request head. Verify the reviewed source and generated dist/index.js at the protected commit before making the check required.

Tools like Dependabot and Renovate understand this format and will open PRs to bump the SHA when a newer commit is available, preserving the comment.

Demo for step 1

2. Pull Request event triggers CLA Workflow

CLA action workflow will be triggered on Pull Request opened, edited, closed, reopened, synchronize, ready_for_review events. This workflow will always run in the base repository and that's why we are making use of the pull_request_target event. The action validates the live Pull Request state, opener, base repository ID, base branch, head repository ID, head branch, and head commit before it writes signature data.

The action fails closed for every unlinked primary commit author. Git names and email addresses are not authenticated and can be forged, and allowlist-ids cannot match an unresolved identity. The git committer field is ignored entirely: it records who applied a commit (a maintainer, GitHub's web-flow merge, a rebase tool), not who holds the copyright, so GitHub <noreply@github.com> merge commits from the "Update branch" button never block a check.

Signers are the authenticated Pull Request opener plus every primary commit author that GitHub maps to an account. A ledger signature belongs to an account ID and is reused in every later Pull Request, whichever role that account plays. Co-authored-by trailers are unverified text that commonly names pairing partners and AI coding agents; they satisfy the opener author/co-author guard but never create a signing obligation. A committer-only match does not satisfy the opener guard.
When the CLA workflow is triggered on pull request closed event and the Pull Request was merged, it will lock the Pull Request conversation with GitHub's resolved reason so that the contributors cannot modify or delete the signatures (Pull Request comment) later. The action re-fetches the closed Pull Request and matches its immutable base repository, base branch, opener, and merge state. A later source branch advance or deletion does not prevent locking. This feature is optional. A failed lock request fails the action. The action never removes a conversation lock. A maintainer must unlock a reopened Pull Request before contributors can sign.

The action fails closed when a Pull Request has more than 1,000 commits, more than 100,000 git identity assertions, more than 1,000 comments, or combined comment bodies over 10,000,000 UTF-8 bytes. Bodies over 65,536 UTF-8 bytes are discarded as non-matching comments because signing declarations must match the complete short phrase exactly, but their bytes still count toward the aggregate response bound. Invalid comment data fails closed. The identity bound is the finite envelope of 1,000 commits with up to 100 author/co-author identities per commit. A signature ledger also fails closed above 10,000 entries or 1,000,000 bytes. The byte limits bound the validated response data before any downstream comment or ledger writes. These limits bound work on untrusted Pull Request and ledger data. Split a larger contribution or start a new versioned ledger before running the CLA check.

3. Signing the CLA

CLA workflow creates a comment on Pull Request asking contributors who have not signed the CLA to sign and fails the CLA Assistant GitHub Actions job. Contributors must post a new comment with "I have read the CLA Document and I hereby sign the CLA" as the full raw Pull Request comment body. Leading or trailing whitespace, blank lines, case changes, wording changes, punctuation, and internal whitespace changes do not count. An edited issue_comment does not trigger the workflow, and an edited declaration remains invalid. Put recheck in a separate new comment. Only a comment author that GitHub identifies as a User with a positive numeric account ID can sign. Bot, organization, mannequin, missing-type, and invalid-ID actors fail closed. If the contributor has already signed the CLA, the CLA Assistant job succeeds. The GitHub Actions runner publishes that job as the Pull Request check; this action does not create a separate commit status or check run.

This action does not rerun an earlier workflow after it records a signature. Repositories that need an immediate required-check update must use a separate trusted job. That job must authenticate the exact signing event, bind the rerun to the current Pull Request number, head commit SHA, workflow file, and base branch, and then call the Actions rerun API. The sample signer has no actions: write permission and is advisory for issue_comment runs by design.

The action does not automatically retry GitHub API requests. A transient GitHub failure fails the current run, which can then be rerun after GitHub recovers. This avoids duplicate comments or ledger writes when GitHub completed a state change but its response was lost.

Demo for step 2 and 3

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 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'.

Protect the signature ledger from normal collaborator writes. Use a repository ruleset that permits only the trusted CLA automation identity, or store the ledger in a private repository where only that identity can write. The action token or configured App/PAT must have permission to update the protected target.

If you split merged-pull-request locking into another job, keep the signer group as cla-signatures-${{ github.repository }}-${{ github.event.pull_request.number || github.event.issue.number }} and give the lock job the distinct cla-lock-${{ github.repository }}-${{ github.event.pull_request.number || github.event.issue.number }} group. Set cancel-in-progress: false in both groups. The lock and signer jobs may overlap, but each must validate the live Pull Request immediately before its write. Separate groups prevent a pending lock run from replacing a signer run.

Ledger entries do not contain a CLA document hash or terms version. If the CLA text changes, use a new ledger path and signing declaration, and require contributors to sign again. Without this policy, an old ledger entry cannot prove which document version the contributor accepted.

The signature can be also stored in a remote repository which can be done by enabling the optional inputs remote-organization-name: <your org name> and remote-repository-name: <your repo name> in your CLA workflow file.

NOTE: You do not need to create this file manually. Our workflow will create the signature file if it does not already exist. Manually creating this file will cause the workflow to fail.

Demo for step 4

5. Authenticated opener ID allowlist

Use allowlist-ids for maintainers and documented automation accounts that never need to sign. Values are comma-separated numeric GitHub database IDs. A configured ID is exempt as the Pull Request opener and as a primary commit author, and an allowlisted opener also bypasses the opener-authorship hard-fail. Unlinked identities have no ID and can never match. The deprecated allowlist name, email, and glob input is ignored because commit metadata can spoof those values.

Demo for step 5

6. Adding Personal Access Token as a Secret

Do not configure PERSONAL_ACCESS_TOKEN when signatures stay in the current repository. For a remote signature repository, create a repository secret with that name. Prefer a fine-grained token limited to the remote repository with Contents read and write access. A classic repo token is broader than necessary and should be used only when the target cannot use a fine-grained token.

Demo for step 6

Environmental Variables:

Name	Requirement	Description
GITHUB_TOKEN	required	Usage: 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
PERSONAL_ACCESS_TOKEN	optional	Required only for a remote signature repository. Use a fine-grained token limited to that repository with Contents read and write access, and store it as PERSONAL_ACCESS_TOKEN.

Inputs Description:

Name	Requirement	Description	Example
mode	optional	sign (default) runs the ledger-backed signer. signer-preflight performs read-only live Pull Request and exact-comment identity admission and emits signer_authorized; it never writes the ledger or Pull Request comments. Use it in a gate with only contents: read, pull-requests: read, and issues: read.	sign
path-to-document	required	Non-empty absolute HTTPS URL of the CLA or DCO document. The action validates it before any GitHub write.	<REPLACE_WITH_CLA_URL>
path-to-signatures	optional	Path to the JSON file where all the signatures of the contributors will be stored inside the repository.	signatures/version1/cla.json
branch	optional	Branch in which all the signatures of the contributors will be stored and Default branch is master.	master
required-base-ref	optional	Only a Pull Request with this live base branch can write signature data or be locked after merge. The secure default is main. Set this input explicitly when the contribution branch has another name.	main
expected-head-sha	optional	Exact head SHA emitted by a preceding signer-preflight job. The signer fails closed when the live Pull Request head differs. Leave empty when no cross-job head binding is needed.	${{ steps.preflight.outputs.head_sha }}
expected-base-sha	optional	Exact base commit SHA emitted by a preceding signer-preflight job. The signer fails closed when the live Pull Request base differs, including after a base-branch advance. Leave empty when no cross-job base binding is needed.	${{ steps.preflight.outputs.base_sha }}
expected-comment-id	optional	REST ID of the exact signing comment emitted by signer-preflight. Set this together with the creation timestamp and author ID to prevent a writer from accepting another exact declaration on the same Pull Request.	${{ steps.preflight.outputs.comment_id }}
expected-comment-created-at	optional	Exact creation timestamp emitted by signer-preflight for the authenticated signing comment. Required when expected-comment-id is set.	${{ steps.preflight.outputs.comment_created_at }}
expected-comment-author-id	optional	Numeric GitHub account ID emitted by signer-preflight for the authenticated signing comment. Required when expected-comment-id is set.	${{ steps.preflight.outputs.comment_author_id }}
allowlist-ids	optional	Comma-separated numeric GitHub user IDs that never need to sign, as the opener or as a primary commit author. Unlinked identities cannot match.	Maintainer and reviewed automation account IDs.
allowlist	deprecated	Ignored. Raw names, emails, and globs are unsafe identity evidence.
remote-repository-name	optional	provide the remote repository name where all the signatures should be stored .	remote repository name
remote-organization-name	optional	provide the remote organization name where all the signatures should be stored.	remote organization name
create-file-commit-message	optional	Commit message when a new CLA file is created.	Creating file for storing CLA Signatures.
signed-commit-message	optional	Commit message when a new contributor signs the CLA in a Pull Request.	$contributorName has signed the CLA in $pullRequestNo
custom-notsigned-prcomment	optional	Introductory Pull Request comment to ask new contributors to sign.	Thank you for your contribution and please kindly read and sign our $pathToCLADocument
custom-pr-sign-comment	optional	The signature to be committed in order to sign the CLA.	I have read the Developer Terms Document and I hereby accept the Terms
custom-allsigned-prcomment	optional	pull request comment when everyone has signed	All Contributors have signed the CLA.
lock-pullrequest-aftermerge	optional	Boolean input for locking the pull request after merging. Default is set to true. It is highly recommended to lock the Pull Request after merging so that the Contributors won't be able to revoke their signature comments after merge	false
suggest-recheck	optional	Boolean input for indicating if the action's comment should suggest that users comment recheck. Default is set to true.	false
use-dco-flag	optional	Boolean input. Set to true to run the action in DCO (Developer Certificate of Origin) mode instead of CLA mode. The bot's prompts and persistence logic use DCO wording. Default is false.	true
require-opener-as-author	optional	Boolean input. When true (the default), fail the check if the Pull Request opener is not recorded as an author or co-author of any commit. Committer metadata does not qualify. Set to false for legitimate cherry-pick or patch-submission workflows.	true

Outputs

Name	Description
signer_authorized	In signer-preflight mode, set to 'true' only when the current newly-created, exact, unedited declaration is authored by an authenticated identity in the live Pull Request's primary author or opener set. The write-capable signer must repeat its live checks; this output is not a bearer authorization token.
cla_passed	Set to 'true' only after the write-capable signer has confirmed that every required contributor is signed and successfully applied the final all-signed CLA bot comment. It is 'false' for signer-preflight, unsigned, closed, and error runs. It is independent of signature_recorded, which can be 'true' while another contributor remains unsigned.
signer_decision	In signer-preflight mode, authorized means the declaration passed identity policy, unauthorized means an exact current declaration failed identity policy, and error means validation or a GitHub request failed. The action fails the job for both unauthorized and error; in sign mode it remains error.
head_sha	In signer-preflight mode, the exact live Pull Request head SHA observed after validation. Pass it to the writer as expected-head-sha to reject a force-push between jobs.
base_sha	In signer-preflight mode, the exact live Pull Request base SHA observed after validation. Pass it to the writer as expected-base-sha to reject a base-branch advance between jobs.
comment_id	In signer-preflight mode, the REST ID of the exact unedited signing comment authenticated by this run. Pass it to the writer as expected-comment-id.
comment_created_at	In signer-preflight mode, the exact creation timestamp of the authenticated signing comment. Pass it to the writer as expected-comment-created-at.
comment_author_id	In signer-preflight mode, the numeric GitHub account ID authenticated as the signing comment author. Pass it to the writer as expected-comment-author-id.
opener_not_in_commits	Set to 'true' when the Pull Request opener is not recorded as an author or co-author of any commit in the PR. Emitted regardless of whether require-opener-as-author caused the check to fail.
signature_recorded	Set to 'true' only after this run persists a new signature in the ledger.

Contributors

Akshay Iyyadurai Balasundaram	Lawrence Chen	Iain McGinniss	Michael Spengler	Anand Chowdhary	Rick M
Filip Moroz	Mikhail	Peter Schmalfeldt	Matt Rosno	Or Geva	Robert Pająk
Scott Brenner	Silvio	Azzam S.A	Alexis Lothoré	Andrew Lohr	Ayman Bagabas
Charlie Fish	Darrell Warde	Jan Holthuis	Nathan Walters	Rokas Kupstys	Shun Kakinoki
Simon Meggle	Tate Berenbaum	Timo Tijhof	Andrew Gable	Knanao	Peter
Self Not Found	Woyaoshunlibiye	Yahav Itzhak

License

Contributor License Agreement assistant

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.