[bradhe]

Adds a Contributor License Agreement requirement for pull requests.

• CLA.md: individual CLA based on the Apache ICLA v2.2, with open items marked for legal review
• .github/workflows/cla.yml: CLA Assistant Lite workflow (pinned to v2.6.1 by commit SHA); signatures are stored in-repo under signatures/version1/
• CONTRIBUTING.md: short section explaining the signing flow

Note: the workflow uses pull_request_target, so enforcement only takes effect once this reaches main. Making the CLA status check required on main (branch protection) is a separate manual step.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c6edacae-8d51-43c4-ac20-7f5008cd3dac

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[jo-sm]

A couple questions from my side:

1. If someone writes the phrase in a comment in PR A, and that PR gets closed, will then PR B require the phrase again?
2. Is there a way to allowlist us who are in the organization? I don't see anything about it in the PR (maybe the action takes care of it?), but I think it would be a bit cumbersome if anyone who does something in the CLI who's working for Tower has to sign off first.

[bradhe]

If someone writes the phrase in a comment in PR A, and that PR gets closed, will then PR B require the phrase again?

Yeah until signatures/version1/cla.json gets updated, which I think we'll need to do operationally in the PR before we land it. There are more complicated solutions, but given the volume of third-party contributions we get, I don't think it's worth adopting for now 'till it becomes a problem.

Versioning the file also makes it trivially auditable, which I like.

Is there a way to allowlist us who are in the organization?

I don't see a feature for this in the upstream. I'll attach a file to this PR with everyone in it already, and we'll just need to remember to do that as part of onboarding at Tower. Also, we'll get reminders, obviously, in the PRs that people open...

[konstantinoscs]

Just two things on my side:

1. cla.json targets main but at the same time main is protected. Shouldn't CLAs go through the develop -> main route like everything else?
2. We should require the CLA on develop, not main. That's where contributions will be

Also, funny enough, I think that the way we check for the "agreement" can be tricked with a phrase like “I hereby sign … but I do not agree” which will be accepted

[bradhe]

Ah it looks like the action will directly update cla.json via the GitHub Contents API, so to @jo-sm 's question, it won't be necessary to update it manually theoretically (we should try this out). But anyway, the question is where should the content be stored. develop seems like the right place as it's the default branch. We'll need to slightly loosen our branch protection rules for this, I'm working on it.

With regard to where the CLA is required, it's basically everywhere: We don't set a target branch.

Claude's developed a solution to your poisoned comment topic, too. Good find.

[devin-ai-integration]

Re-read the updated version — app-token routing via remote-organization-name/remote-repository-name and the custom-pr-sign-comment exact-match fix both look right. Two things left:

?ref=${{ github.ref }} on the allowlist fetch resolves differently per event. For pull_request_target it's the base branch (refs/heads/develop), but for issue_comment it's the default branch (main) — and signing happens through issue_comment. So until this lands on main, the signing path fetches .github/cla-allowlist.txt from a branch where it doesn't exist. That won't fail loudly either: list=$(gh api ... | base64 -d | grep ... | paste -sd, -) takes its exit status from paste, so a failed gh api yields an empty allowlist and dependabot/employees get prompted to sign instead of being skipped. Pinning the ref explicitly (?ref=develop, matching branch: 'develop') plus set -euo pipefail fixes both.

path-to-document still points at blob/main/CLA.md. Signatures now go to develop, but the doc link 404s for contributors until the next develop→main release merge. blob/develop/CLA.md is consistent with the rest of the config.

Also, now that LICENSE says GmbH, pyproject.toml:9 (authors = [{ name = "Tower Computing Inc." ...}]) and flake.nix:25/:50 are the last two spots still saying Inc.

(Still no concurrency group — opened + synchronize landing together can race on the cla.json write.)

[konstantinoscs]

Lgtm!

Also, two comments from Sol, not very important to me to block on but I leave them here:

1. Add set -euo pipefail before the allowlist pipeline so API/decoding failures cannot silently produce an empty list.

2. Confirm the company rename: the PR changes the license to GmbH, while pyproject.toml and flake.nix still say Inc.