Connect a Google Cloud project: by script

The canonical source for this path is thoughtgears/bobbin-onboarding, a public repository that exists specifically to be read before it is run — there is no installer, no binary, and no step that phones home. This page quotes the commands that matter; the repository is the up-to-date spec.

You will need two values from your workspace, shown on the Connect a Google Cloud project step in the console:

• TENANT_SA — your dedicated service account, shaped like tenant-<id>@bobbin-shard-<n>.iam.gserviceaccount.com
• TOPIC — your alert intake topic, shaped like projects/bobbin-hub-<n>/topics/tenant-<id>-alerts

Run the script

git clone https://github.com/thoughtgears/bobbin-onboarding.git
cd bobbin-onboarding
./grant-bobbin-access.sh \
  --tenant-sa "$TENANT_SA" \
  --topic "$TOPIC" \
  --project "$PROJECT_ID" \
  --dry-run

--dry-run prints every command the script would run and changes nothing. Read the output, then run the identical command again with --dry-run removed. The script needs the beta gcloud component (gcloud components install beta) for the notification channel, and it is safe to re-run — the IAM grants are idempotent and it will not create a second channel.

Success looks like a line reading Done — one thing left, and it is on our side, followed by a project number. Send that number to support@getbobbin.dev or through the console — alerts cannot flow until Bobbin’s own side grants your project’s Cloud Monitoring service agent publish rights on your topic, and that step needs the project number.

What it does, command by command

On every project you name, the script grants the four roles from the overview page:

for ROLE in roles/logging.viewer roles/monitoring.viewer \
            roles/errorreporting.viewer roles/run.viewer; do
  gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member "serviceAccount:$TENANT_SA" --role "$ROLE" --condition=None
done

Then it creates the notification channel Bobbin’s alerts arrive through, skipping the step if one already points at your topic:

gcloud beta monitoring channels create \
  --project "$PROJECT_ID" \
  --display-name "Bobbin (@bobby)" \
  --type pubsub \
  --channel-labels "topic=$TOPIC"

That is the complete list of writes the script makes on your project — two kinds of command, run once per project, and nothing else.

Domain-restricted sharing

If your organisation enforces iam.allowedPolicyMemberDomains, the first gcloud projects add-iam-policy-binding call fails with FAILED_PRECONDITION, and the raw error does not name the policy. The script deliberately does not pre-check this: reading org policy needs the Org Policy API, and if it is disabled gcloud offers to enable it for you — a write, on your project, from a procedure that promises to change nothing. If you hit this failure, add a conditional exception for the Bobbin organisation (ask support for the organisation id) or a project-level override, then re-run — the script is idempotent and picks up exactly where it stopped.

Removing access

./revoke-bobbin-access.sh --tenant-sa "$TENANT_SA" --project "$PROJECT_ID" --dry-run

The exact reverse: it removes the four role bindings and deletes the notification channel. Your alert policies are left alone — they keep working with whatever other channels they have.