Contributor agreement [improved] #21
Conversation
New models ContributorAgreement and SignedContributorAgreement are introduced.
A new Settings > Contributor Agreements page is introduced.
The page allows a user to review the text of existing contributor agreements
and to sign any of them.
A new /api/v1/users/{username}/contributor-agreements/{slug} endpoint allows to
check if a user has signed a contributor agreement.
This api endpoint can be used by a gitea action workflow, e.g. like this:
```
name: contributor agreement check
on:
pull_request_target:
types: [opened, ready_for_review, reopened, review_requested]
env:
CONTRIBUTOR_AGREEMENT: ...
jobs:
check_api:
runs-on: ...
steps:
- run: echo "Checking $CONTRIBUTOR_AGREEMENT for ${{ gitea.event.pull_request.user.login }}"
- run: result=$(curl --show-error --silent "$GITHUB_API_URL/users/${{ gitea.event.pull_request.user.login }}/contributor-agreements/$CONTRIBUTOR_AGREEMENT"); if [ "$result" == "OK" ]; then exit 0; else echo $result; exit 1; fi
```
changed in b0936f4
komarov
force-pushed
the
contributor-agreement2
branch
from
7aaf423 to
d0bca15
Compare
|
@brechtvl @bartvdbraak here are the updates for the CLA check implementation (mentioned in PR description above). I don't particularly like the coupling of the CLA signing code with the workflow reruns, but as the user testing showed we need to have some automation and this seemed like the only realistic place to put it. One alternative is to remove this automation and to instruct the user to close/reopen the PR, but this feels rather clumsy as an interface. |
brechtvl
left a comment
brechtvl
left a comment
There was a problem hiding this comment.
The coupling seems unavoidable and with CLAs on GitHub something similar happens.
I have just one comment after read through the implementation.
|
|
||
| // rerunFailedActions looks for recent cla.yml failures triggered by the user and reruns those. | ||
| func rerunFailedActions(ctx *gitea_context.Context, user *user_model.User) error { | ||
| runs, err := db.Find[actions_model.ActionRun](ctx, actions_model.FindRunOptions{ |
There was a problem hiding this comment.
Does this return the 10 most recent runs? It wasn't obvious to me looking at the FindRunOptions implementation.
If not that could cause problems especially when a user needs to sign a second CLA a long time after the first one.
There was a problem hiding this comment.
Yes, the order is defined in https://github.com/go-gitea/gitea/blob/01351cc6c792635568872e6766445a573368144a/models/actions/run_list.go#L125
If that changes unexpectedly we will have a problem though. Maybe there's is a simple way to guarantee the order.
An iteration upon the closed #15 (first 4 commits have been copied over).
New models ContributorAgreement and SignedContributorAgreement are introduced.
A new Settings > Contributor Agreements page is introduced.
The page allows a user to review the text of existing contributor agreements
and to sign any of them.
A new /api/v1/users/{username}/contributor-agreements/{slug} endpoint allows to
check if a user has signed a contributor agreement.
This api endpoint can be used by a gitea action workflow as described in https://projects.blender.org/infrastructure/clacheck-runner
Updated in this iteration:
SignContributorAgreementfunction now searches for failedcla.ymlworkflows that were triggered by the current user and reruns them (search limited to 10 latest workflow runs). This updates the failed check status automatically and doesn't require any additional actions from the user.In addition to these changes the runner code (https://projects.blender.org/infrastructure/clacheck-runner) was updated to automatically post a pull request comment when a check fails: