ci: point the CLA action at a branch that exists

[onamfc]

Summary

The cla check fails on every open PR — #34, #36, #37 and #38 — and has been for as long as the workflow has existed:

##[error]Could not retrieve repository contents. Status: 404

Nothing is wrong with the PRs. cla-assistant/github-action defaults its branch input to master, this repo's default branch is main, and no master ref exists. The action's first call asks for the signature file on that missing ref:

// src/persistence/persistence.ts
const result = await octokitInstance.repos.getContent({
  owner: ..., repo: ...,
  path: input.getPathToSignatures(),
  ref: input.getBranch()          // <- 'master', which doesn't exist here
})

so it 404s before doing anything else. The run log confirms the defaults it was using:

path-to-signatures: ./signatures/cla.json
branch: master

Changes

1. branch: 'main' — so the ref resolves. path-to-signatures is now pinned explicitly too, since the two inputs only make sense read together and the pair is what a future reader needs to see.

2. contents: write — the same module writes the signature file when someone signs:

export async function createFile(contentBinary) {
  return octokitInstance.repos.createOrUpdateFileContents({ ..., branch: input.getBranch() })
}

With contents: read this would have 403'd on the write the moment the read started working, so fixing only the branch would have traded one failure for another.

3. Removed path-to-cla-assistants — not an input this action accepts. It was logged on every run as:

##[warning]Unexpected input(s) 'path-to-cla-assistants', valid inputs are ['path-to-signatures', 'branch', ...]

Verification

The action's action.yml confirms the defaults and the valid input list:

path-to-signatures:
  default: "./signatures/cla.json"
branch:
  description: "provide a branch where all the CLAs are stored"
  default: "master"

Checked against this repo:

Check	Result
master ref exists?	No — only main and feature branches
signatures/cla.json on main?	Does not exist yet; the action creates it on first signature
main branch protection	None, so the action's commit will land
CLA_ASSISTANT_PAT secret	Present — though unused here, since it only applies to remote-repo storage
YAML parses	Yes

That last row is worth stating: getPATOctokit() is only reached when remote-repository-name / remote-organization-name are set. Neither is, so this runs on GITHUB_TOKEN and the permissions block above is what actually governs it.

Two things to note

This PR cannot prove itself green. pull_request_target runs the workflow definition from the base branch, not the PR head — so the cla check here still executes main's broken copy and will still fail. That's expected. The fix takes effect on the first PR opened after this merges.

Signature commits land on main. Each new signer produces a signatures/cla.json commit, which triggers CI and Release. semantic-release no-ops on a non-conventional commit message and new signers are rare, so this is noise rather than a problem. If it ever does matter, the alternative is a dedicated cla-signatures branch — but that branch has to be created first, or it reproduces exactly the bug this PR fixes.

Scope

Not a functional change and not related to #35 — split out from #38 deliberately so the redirect fix isn't carrying a CI change. license/cla (the cla-assistant.io status check) has been passing throughout, so signature enforcement was never actually bypassed; only the Action half was broken.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!