Add label to prs that need a CLA signed

[jjspace]

Description

The label is helpful when viewing PRs in other Github views. I've been doing this manually to a few PRs but it should be easily automatable

Issue number and link

no issue

Testing plan

Was a label added to this pr when it was not a conditional check? Then we're good

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[jjspace]

@siddheshranade I recall you did the initial implementation of the CLA check, any ideas why this is not working? Do re-runs of the workflow pull from the latest version of the script on this branch or from main?

[siddheshranade]

@jjspace I remember facing the same issue. Yes, manual re-runs of the workflow will execute the code in main.

A workaround I remember using was to update cla.yaml to trigger the action on a push instead of pull_request_target:

on:
  push:

This way you don't have to manually re-run the workflow, it triggers on every git push, and executes the code on whichever branch you're pushing to. You can reset this YAML file change once you confirm the label is being set.

Correct me in case I'm wrong about this and I'm happy to look into it more deeply.

[jjspace]

Testing this was annoying but I was able to confirm the route to add labels works and it added the correct one. Thanks for the suggestion to switch to push @siddheshranade, that was helpful but github fills in different environment variables for different events so it was still a pain...
I left the commit history to show how the working code changed but it could probably be condensed down into a single commit. Anyway, i'm done playing with this, if we want it it should work, if not i'll leave that up to @ggetz

[ggetz]

Yes, workflows with pull_request_target do not run in the context of the branch for security reasons (as the granted GitHub token has write access). So that means this will not trigger in this or any PR until the code is merged into main.

TLDR; It's a pain to test for a reason.

Automating this label gets a 👍 from me.