Add GitHub Team User Store to tools sources

[JimSuplizio]

This tool simply creates a dictionary of team/users and stores them as a json string in azure blob storage. This is first part of the fix for #4487. The second part of the fix will be modifying CodeOwnersParser to get the list of users for the team and adding them to the Owners instead of throwing them out.

A large part of the why this was done this way was due to the permissions required to access the teams in GitHub. A standard GitHub token cannot have the permissions necessary to read org/team membership. It requires a fine-grained token created by someone with the organization permissions which, unfortunately, excludes bot accounts meaning it has to be from an actual user. The resulting blob string is only 44k and would only need to be pulled by the CodeOwnersParser once, if teams are encountered.

The GitHub token and blob SAS have already been added to the secret-management tool as manual secrets in the azure-sdk-build-tools repository (PR 747). I've also created the variable group, azuresdkartifacts azure-sdk-write-teams variables, which will be used in the pipeline when I create it, after this PR has been merged. Last but not least, this tool won't be published to nuget, the pipeline will build and run the tool as part of the pipeline. Also of note, because it's using a generated GitHub token, it won't affect the repository limits where it runs.

[konrad-jamrozik]

A large part of the why this was done this way was due to the permissions required to access the teams in GitHub. A standard GitHub token cannot have the permissions necessary to read org/team membership.

How the implementation would differ if the standard GitHub token could have the permissions?

The GitHub token and blob SAS have already been added to the secret-management tool as manual secrets in the azure-sdk-build-tools repository (PR 747)

So the GH token you created and put in the KV is your personal token? And the idea is that whomever rotates it next with the secrets tool, will have their own personal token put in KV instead?

I've also created the variable group, azuresdkartifacts azure-sdk-write-teams variables

My brain's English parser throws exception on this, sorry x-D. Is azuresdkartifacts a variable group and azure-sdk-write-teams is a variable belonging to it?

Could you perhaps link to the variable group from the PR description?

What is the purpose of this variable group and variable? I know they will be used in the pipeline, but how?

[weshaggard]

Where is the pipeline that we will be running this tool in?

[konrad-jamrozik]

I think it is to-be-created per PR description:

I've also created the variable group, azuresdkartifacts azure-sdk-write-teams variables, which will be used in the pipeline when I create it, after this PR has been merged.

As I mentioned in another comment, would be cool if the README has a URL of the pipeline when it comes.

[weshaggard]

We should look at including this in the existing pipeline https://github.com/Azure/azure-sdk-tools/blob/main/eng/pipelines/pipeline-owners-extraction.yml.

[JimSuplizio]

@weshaggard and @konrad-jamrozik
I need to get this merged prior to creating the pipeline. Unlike other tools, this won't be being published to the NET dev feed because it's unusable outside of pipeline so there's really no point. The only test that makes sense here is to pull back what was just stored and ensure it matches the dictionary created from the team/user data and this done immediately after the call to store it. The pipeline just needs to build and run the tool to do both.

[JimSuplizio]

A large part of the why this was done this way was due to the permissions required to access the teams in GitHub. A standard GitHub token cannot have the permissions necessary to read org/team membership.

How the implementation would differ if the standard GitHub token could have the permissions?

The standard GitHub Token cannot have Organization->Membership:Read permissions which means they cannot query for team membership. Furthermore, in order to query teams and membership for an org, the account that created the token needs to be a member of Azure. This is something @weshaggard and I have discussed and it was decided to use a generated token.

The GitHub token and blob SAS have already been added to the secret-management tool as manual secrets in the azure-sdk-build-tools repository (PR 747)

So the GH token you created and put in the KV is your personal token? And the idea is that whomever rotates it next with the secrets tool, will have their own personal token put in KV instead?

Yes. The secrets are in the azure-sdk-build-tools repository in the tools/secret-management/manual/AzureSDKEngKeyVault. The json files are azuresdkartifacts-azure-sdk-write-teams-github-pat.json and azuresdkartifacts-azure-sdk-write-teams-sas.json, both of which describe what needs to be done.

I've also created the variable group, azuresdkartifacts azure-sdk-write-teams variables

My brain's English parser throws exception on this, sorry x-D. Is azuresdkartifacts a variable group and azure-sdk-write-teams is a variable belonging to it?

Could you perhaps link to the variable group from the PR description?

What is the purpose of this variable group and variable? I know they will be used in the pipeline, but how?

I don't normally link variable groups in PRs because they're public. This is the variable group that holds these two variables. Like other variables in our pipelines, these are linked to the keyvault secrets and pull their values from there which is the standard. When the values change, after a rotation, the variable group won't need to change because it'll just start pulling the new values.