Skip to content

Default GitHub team members to member role, not maintainer#80

Merged
Alexanderamiri merged 2 commits into
mainfrom
fix/github-team-member-roles
Mar 17, 2026
Merged

Default GitHub team members to member role, not maintainer#80
Alexanderamiri merged 2 commits into
mainfrom
fix/github-team-member-roles

Conversation

@Alexanderamiri
Copy link
Copy Markdown
Member

Summary

  • Team members now get role from their YAML entry (default: member)
  • Only members with role: maintainer can manage the team on GitHub (add/remove repos and members)
  • Previously all members were added as maintainers, which allowed anyone to add repos to their team (granting those repos CI access to the team's AWS role)
members:
  - google: alice.smith
    github: alicesmith
    role: maintainer    # can manage team
  - google: bob.jones
    github: bobjones     # defaults to "member"

Companion: javaBin/registry docs/member-role-field

Test plan

  • Existing teams: next provisioner run will downgrade all members to member unless they have role: maintainer in YAML
  • Verify maintainers can still add repos
  • Verify members cannot add repos

Replace all Secrets Manager usage with SSM Parameter Store SecureString
to eliminate per-secret monthly costs ($0.40/secret/month).

- service-secret module: aws_secretsmanager_secret → aws_ssm_parameter
  at /{project}/apps/{service}/{name}
- service-rds module: remove manage_master_user_password, use
  random_password + SSM parameter at /{project}/apps/{name}/db-master-password
- ECS execution role: secretsmanager:GetSecretValue → ssm:GetParameters
  scoped to parameter/{project}/apps/*
- Identity Center: secretsmanager:Describe/List → ssm:DescribeParameters/GetParametersByPath
- registry.py: update output_map and exports for new resource types
- All docs updated to reflect SSM-only secret storage
Team members now get role from their YAML entry (default: "member").
Only members with role: maintainer can manage the team on GitHub
(add/remove repos and members). Previously all members were maintainers.
@Alexanderamiri Alexanderamiri enabled auto-merge (squash) March 17, 2026 20:42
@github-actions
Copy link
Copy Markdown

Terraform Plan

🚧 Changes detected — Plan: 0 to add, 1 to change, 0 to destroy.

Plan output
Acquiring state lock. This may take a few moments...

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.lambdas.aws_lambda_function.team_provisioner will be updated in-place
  ~ resource "aws_lambda_function" "team_provisioner" {
        id                             = "javabin-team-provisioner"
      ~ last_modified                  = "2026-03-17T19:20:07.000+0000" -> (known after apply)
      ~ source_code_hash               = "DOsqyX7kl+NoVN861D4rN0ieHND77GeWwpYD1A93gdQ=" -> "wX2pv1QxWt5RN/akAYhiGmQHMGivVw80weFw6a1vHPQ="
        tags                           = {}
        # (21 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

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

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

LLM Review

Risk: 🟢 LOW

Routine Lambda function code update for team_provisioner with source code hash change.

  • [routine] Lambda function team_provisioner source code updated (hash change from DOsqyX7kl+NoVN861D4rN0ieHND77GeWwpYD1A93gdQ= to wX2pv1QxWt5RN/akAYhiGmQHMGivVw80weFw6a1vHPQ=). This is an in-place update with no infrastructure changes.
  • [routine] Only metadata fields (last_modified, source_code_hash) are changing. No IAM permissions, environment variables, or function configuration modified.
  • [routine] No resources being created or destroyed. Plan shows 0 additions, 1 modification, 0 deletions - minimal blast radius.
  • [routine] All other infrastructure components (VPC, security groups, IAM roles, monitoring, databases) remain unchanged and stable.
  • [routine] No cost implications - existing Lambda function is being redeployed with new code, no new billable resources provisioned.

@Alexanderamiri Alexanderamiri merged commit 2f0d261 into main Mar 17, 2026
3 checks passed
@Alexanderamiri Alexanderamiri deleted the fix/github-team-member-roles branch March 17, 2026 20:43
Alexanderamiri added a commit that referenced this pull request Mar 17, 2026
## Summary

Root cause fix for the CODEOWNER self-merge regression.

The provisioner was calling `PUT /teams/{slug}/memberships/{user}` on
every run for every member, even when the role was already correct. This
re-added members via the API, changing their membership state from
"org-owner implicit" to "explicit API-added", which caused GitHub to
block self-merge on CODEOWNER-required PRs.

Now fetches current member roles first and only calls PUT when a role
change is actually needed.

## What happened
1. PR #80 changed provisioner to default `role: member`
2. Registry #16 merged → provisioner ran for first time with new code
3. Provisioner called `PUT memberships/alexanderamiri {"role":
"maintainer"}` — role was already maintainer, but the API call changed
the membership source
4. GitHub stopped allowing self-merge on CODEOWNER PRs

## Also reverted
Removed the org-admin bypass actor from the ruleset (was a band-aid, not
the fix).

## Test plan
- [ ] Merge this PR (should be self-mergeable — provisioner hasn't run
again)
- [ ] Trigger provisioner via registry merge
- [ ] Verify team membership unchanged (check GitHub API)
- [ ] Create a test PR → verify self-merge still works
Alexanderamiri added a commit that referenced this pull request May 9, 2026
## Summary
- Team members now get `role` from their YAML entry (default: `member`)
- Only members with `role: maintainer` can manage the team on GitHub
(add/remove repos and members)
- Previously all members were added as maintainers, which allowed anyone
to add repos to their team (granting those repos CI access to the team's
AWS role)

```yaml
members:
  - google: alice.smith
    github: alicesmith
    role: maintainer    # can manage team
  - google: bob.jones
    github: bobjones     # defaults to "member"
```

Companion: javaBin/registry docs/member-role-field

## Test plan
- [ ] Existing teams: next provisioner run will downgrade all members to
`member` unless they have `role: maintainer` in YAML
- [ ] Verify maintainers can still add repos
- [ ] Verify members cannot add repos
Alexanderamiri added a commit that referenced this pull request May 9, 2026
## Summary

Root cause fix for the CODEOWNER self-merge regression.

The provisioner was calling `PUT /teams/{slug}/memberships/{user}` on
every run for every member, even when the role was already correct. This
re-added members via the API, changing their membership state from
"org-owner implicit" to "explicit API-added", which caused GitHub to
block self-merge on CODEOWNER-required PRs.

Now fetches current member roles first and only calls PUT when a role
change is actually needed.

## What happened
1. PR #80 changed provisioner to default `role: member`
2. Registry #16 merged → provisioner ran for first time with new code
3. Provisioner called `PUT memberships/alexanderamiri {"role":
"maintainer"}` — role was already maintainer, but the API call changed
the membership source
4. GitHub stopped allowing self-merge on CODEOWNER PRs

## Also reverted
Removed the org-admin bypass actor from the ruleset (was a band-aid, not
the fix).

## Test plan
- [ ] Merge this PR (should be self-mergeable — provisioner hasn't run
again)
- [ ] Trigger provisioner via registry merge
- [ ] Verify team membership unchanged (check GitHub API)
- [ ] Create a test PR → verify self-merge still works
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant