Replace libkubo's admin to w3dt-stewards

[Jorropo]

Summary

Give w3dt-stewards team maintain permissions to libkubo repository.

Why do you need this?

Kubo maintainters should be able to perform the same actions on libkubo that they can on kubo repository.

What else do we need to know?

n/a

DRI: myself

[github-actions]

Before merge, verify that all the following plans are correct. They will be applied as-is after the merge.

Terraform plans

ipfs

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # github_team_repository.this["w3dt-stewards:libkubo"] will be created
  + resource "github_team_repository" "this" {
      + etag       = (known after apply)
      + id         = (known after apply)
      + permission = "maintain"
      + repository = "libkubo"
      + team_id    = "4656983"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

[galargh]

To add permissions for a team, it has to be specified under the teams (

github-mgmt/github/ipfs.yml

Line 4804 in aa2c822

teams:

) block instead of collaborators (

github-mgmt/github/ipfs.yml

Line 4795 in aa2c822

collaborators:

). I moved giving permissions to w3dt-stewards there.

Also, I restored a description. Descriptions are useful for reviewers but also for anyone in the future that might end up here.

[Jorropo]

@galargh thx but I don't understand the difference, terraform seemed happy with what I originally sent:

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  - destroy

Terraform will perform the following actions:

  # github_repository_collaborator.this["libkubo:guseggert"] will be destroyed
  # (because key ["libkubo:guseggert"] is not in for_each map)
  - resource "github_repository_collaborator" "this" {
      - id         = "libkubo:guseggert" -> null
      - permission = "admin" -> null
      - repository = "libkubo" -> null
      - username   = "guseggert" -> null
    }

  # github_repository_collaborator.this["libkubo:w3dt-stewards"] will be created
  + resource "github_repository_collaborator" "this" {
      + id                          = (known after apply)
      + invitation_id               = (known after apply)
      + permission                  = "admin"
      + permission_diff_suppression = false
      + repository                  = "libkubo"
      + username                    = "w3dt-stewards"
    }

Plan: 1 to add, 0 to change, 1 to destroy.

[galargh]

github_repository_collaborator.this["libkubo:w3dt-stewards"] will be created

With the original plan, the apply would have tried to create github_repository_collaborator resource. That resource represents relationship between repositories and users. The apply would have failed because user w3dt-stewards doesn't exist.

We might be able to catch cases like this with some additional checks. I created ipdxco/github-as-code#91 to track this. But, if I'm not mistaken, it is possible to user names and team names do not share a pool so if w3dt-stewards user existed, it would have been a totally valid plan.

github_team_repository.this["w3dt-stewards:libkubo"] will be created

The updated plan proposes creation of github_team_repository resource. This resource represents relationship between repositories and teams. As expected, the apply succeeded because we do have a team called w3dt-stewards.