Team Management Automation Enhancement: Add team linter workflow and linter script

[jspaleta]

This enhances team-management automation by adding a linter workflow to be run on pull requests that involve the ladder/teams directory

The linter script uses a GitHub API token provisioned with Cilium Organization membership read access to discover all current GitHub Cilium Org logins and will compare logins listed in the team management yaml files located in ladder/teams and will fail if the team management files reference a GitHub login that is not already a member of the Cilium GitHub org. This will also lint for simple human errors such as login casing (GitHub logins are case sensitive)

Note 1:

The workflow included here is inoperable until there is a correctly named/provisioned token secret with read-only access to cilium org membership in the team-management environment. I'll need to sync with the Cilium org admins to get that provisioned as part of merging this PR.

Note 2:

Adding new logins to the GitHub Cilium Org is still beyond the scope of the team management automation and requires the manual action of GitHub Cilium Org admins, but once a GitHub login is added as an Org member, they can be added/removed to teams via file edits to files under ladder/teams. This linter should be enough to alert to situations where a new team members needs to be first added to the cilium org.

Note 3:

I've tested a version of the linter script in the MillionDollarIdeas.
You can see example failure output here:
https://github.com/MillionDollarIdeas/team-assignments/actions/runs/13151412034/job/36699409589

[jspaleta]

I've implemented this in the MillionDollarIdeas org to fire on PR changes as a test
Here a test PR with multiple commits to cause the linter pass/fail:
MillionDollarIdeas/team-assignments#2
Here's the action history for the workflow:
https://github.com/MillionDollarIdeas/team-assignments/actions/workflows/team-lint.yaml

[joestringer]

Note (for me): Set up this token.

[joestringer]

May be worth checking whether this list is truncated.. I suspect that there's pagination going on, given the number of org members.

[jspaleta]

updated in new commit

[joestringer]

May be worth checking whether this list is truncated.. I suspect that there's pagination going on, given the number of org members.

[jspaleta]

updated in commit

[joestringer]

For the recent additions to the org, I have merged these files first and then run a sync script that detects such member cases and adds them into GitHub. This linter reverses this, meaning that the member would have to be in the GitHub org first before we sync. Will need new scripting to work this way.

[joestringer]

That said I think there's multiple ways to solve this, but having a linter like this in this repo seems like the right approach. Maybe I'll just rethink the sync script or rip it out and go back to the old process for adding new members.

[jspaleta]

I look at it this way this linter is a reminder to run the sync. Worst case is you rekick the failed workflow after the sync and that should clear the PR for merge.

[jspaleta]

but the sync could run against the PR checkout right?

[jspaleta]

I guess I could rebuild the linter logic just to check for casing errors but wrong/missing org login seems like a good thing to catch.

[joestringer]

yep sync could be run against the PR checkout.

[jspaleta]

@joestringer
Okay I've updated the linter logic a little I now have it reporting the http 401 status. So I think the next thing to do is get the token secret in place with the right permissions and we can see if this runs to completion with the newly added pagination support

[joestringer]

Which permissions are necessary for the token? Could we use automatic token authentication? In other words, are the required permissions listed here?

[jspaleta]

@joestringer sadly its Org scoped permissions not Repo scoped so I dont think the automatic perms work.

Needed perms are organizational member read access.

I'm attaching a screenshot from the MillionDollarIdeas personal access token settings I'm using to test the script logic currently.

[joestringer]

OK. Have you tried creating an "external contribution" from a different repository onto the Million Dollar Ideas repo to test this? What I'm wondering is, if an external contributor creates a PR against this repository, will the workflow be able to successfully access the secret in order to perform this linting step? I ask because of this workflow using pull_request which I would expect to not have access to secrets by default. If not then we need to put more thought into how this linter is going to work.

[jspaleta]

let me try to create a throw away github account and do a test on MDI.. hold please

[jspaleta]

Okay this is really weird The linter isn't firing at all in MDI org now, but it definitely fired last week as seen in the actions log for the MDI repo. Need to sort out why this isn't firing on pull_request there at all.

[jspaleta]

okay sorted it out on MDI.

@joestringer I think you are correct.
Pull request from repo branch works fine:
https://github.com/MillionDollarIdeas/team-assignments/actions/runs/13294953690
Ends with error due to linter detecting missing login from org

Pull request from forked repo branch gets 401 error:
https://github.com/MillionDollarIdeas/team-assignments/actions/runs/13294917255/job/37124458634
Ends with 401 error trying to pull org members.

[joestringer]

@jspaleta hmm yeah that was my concern. I think whatever linting we do in public, ideally that can just work for any submitted PR. If we could verify that the specified usernames exist in the generic GitHub API without any privileges into the Cilium organization then maybe that would be sufficient for that particular check?

[jspaleta]

@joestringer
I'll need to poke a little... but doing the naive thing doesn't catch the most obvious casing problems.
ex:

https://api.github.com/users/jspaleta
https://api.github.com/users/JsPaLeTa

both urls return info, but you can't actually use the camelcase programmatically in the post data to update teams.

Its the very fact that github api urls are case-insensitive but the actual usernames are case sensitive when used as API data payloads that actually causes the need to lint.
shakes fists in rage and bellows into the sky

I'm gonna need to parse the json output of the get username url for the 'login' field which is the correct case sensitive data. I'll poke once I refactor a new version and commit.