Skip to content

Support members.yaml rename and access group syncing#101

Merged
Alexanderamiri merged 2 commits into
mainfrom
refactor/members-and-access-groups
Mar 26, 2026
Merged

Support members.yaml rename and access group syncing#101
Alexanderamiri merged 2 commits into
mainfrom
refactor/members-and-access-groups

Conversation

@Alexanderamiri
Copy link
Copy Markdown
Member

Summary

  • Renames scripts/sync-heros.pyscripts/sync-members.py with type field support
  • Updates scripts/provision-groups.py to accept access.yaml and pass access groups to Lambda
  • Adds access group sync to team-provisioner Lambda: syncs nested group membership (role groups → access groups) for Google Workspace service access control
  • Updates CLAUDE.md scripts table

Companion PR: javaBin/registry (refactor/members-and-access-groups)

How access groups work

The Lambda adds role group emails (e.g. helter@java.no) as members of access groups (e.g. email-access@java.no). Google Admin Console group-based overrides then enable the corresponding service for all members of the access group.

Test plan

  • CI passes (plan + review)
  • Merge this PR first (before registry PR)
  • Verify access group sync works after registry PR triggers provisioning

- Rename scripts/sync-heros.py → scripts/sync-members.py with type field
- Update provision-groups.py to accept access.yaml and pass to Lambda
- Add access group sync to team-provisioner Lambda: syncs nested group
  membership (role groups → access groups) for Workspace service control
- Update CLAUDE.md scripts table

Companion to registry refactor/members-and-access-groups branch.
@Alexanderamiri Alexanderamiri requested a review from a team as a code owner March 26, 2026 20:44
@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-26T20:37:00.000+0000" -> (known after apply)
      ~ source_code_hash               = "jsKGWwFMmlUixdZyuNYiJ/4JdwuXeac/mjIxmWOe4cU=" -> "7DSejz3Xn0CiM4UkSgYjwAnhf5pjehbiOrllxTrgfeM="
        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 update for team_provisioner with source code hash change.

  • [routine] Lambda function team_provisioner source code updated (hash change from jsKGWwFMmlUixdZyuNYiJ/4JdwuXeac/mjIxmWOe4cU= to 7DSejz3Xn0CiM4UkSgYjwAnhf5pjehbiOrllxTrgfeM=). This is an in-place update with no infrastructure changes.
  • [routine] Only metadata fields updated: last_modified timestamp will be refreshed. No functional configuration changes to the Lambda function.
  • [routine] No IAM permissions, security groups, or access controls modified. All 21 other Lambda attributes remain unchanged.
  • [routine] No resources being created or destroyed. Single in-place modification with zero infrastructure impact.
  • [routine] No cost implications. Lambda function already exists; this is a code deployment, not a new resource or scaling change.

- Add REGION_MAP for mapping form region values to group names
- Add region column to COLUMN_MAP
- Set type: helt for sheet-synced entries
@github-actions
Copy link
Copy Markdown

Terraform Plan

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

Plan output

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-26T20:37:00.000+0000" -> (known after apply)
      ~ source_code_hash               = "jsKGWwFMmlUixdZyuNYiJ/4JdwuXeac/mjIxmWOe4cU=" -> "7DSejz3Xn0CiM4UkSgYjwAnhf5pjehbiOrllxTrgfeM="
        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 jsKGWwFMmlUixdZyuNYiJ/4JdwuXeac/mjIxmWOe4cU= to 7DSejz3Xn0CiM4UkSgYjwAnhf5pjehbiOrllxTrgfeM=). This is an in-place update with no infrastructure changes.
  • [routine] Only metadata fields updated: last_modified timestamp will be refreshed. No functional configuration changes to the Lambda function.
  • [routine] No IAM policy changes, no security group modifications, no resource destruction, and no new billable resources being created.
  • [routine] All 100+ existing infrastructure resources remain unchanged - VPC, networking, monitoring, ECR repositories, IAM roles, and other services are untouched.
  • [routine] Plan shows 0 resources to add, 1 to change (in-place), 0 to destroy - minimal blast radius.

@Alexanderamiri Alexanderamiri merged commit 0738911 into main Mar 26, 2026
3 checks passed
@Alexanderamiri Alexanderamiri deleted the refactor/members-and-access-groups branch March 26, 2026 20:53
Alexanderamiri added a commit that referenced this pull request May 9, 2026
## Summary
- Renames `scripts/sync-heros.py` → `scripts/sync-members.py` with
`type` field support
- Updates `scripts/provision-groups.py` to accept `access.yaml` and pass
access groups to Lambda
- Adds access group sync to team-provisioner Lambda: syncs nested group
membership (role groups → access groups) for Google Workspace service
access control
- Updates CLAUDE.md scripts table

**Companion PR:** javaBin/registry (refactor/members-and-access-groups)

## How access groups work
The Lambda adds role group emails (e.g. `helter@java.no`) as members of
access groups (e.g. `email-access@java.no`). Google Admin Console
group-based overrides then enable the corresponding service for all
members of the access group.

## Test plan
- [ ] CI passes (plan + review)
- [ ] Merge this PR first (before registry PR)
- [ ] Verify access group sync works after registry PR triggers
provisioning
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