GitHub

What's on this screen

The GitHub panel configures the singleton GitHub Commit Provider used for delegated Git-backed work. The provider is a GitHub App, not a classic OAuth App.

How to configure GitHub

1. Open Org Settings and select GitHub.
2. Copy the callback URL shown under GitHub commit provider.
3. Register that exact callback URL on the GitHub App used for commit access and enable expiring user tokens.
4. Fill in Client ID.
5. Fill in Client secret.
6. Paste the App's Private key PEM.
7. Click Test configuration. Vibedata authenticates as the App, validates its identity and permission map, and lists the organizations where the App is installed. Testing does not change the saved provider.
8. Choose the Default organization for Demo Provisioning. Vibedata preselects the first organization; choose another when needed.
9. Click Save. Vibedata checks the selection again and saves the provider and its Demo Provisioning target together without opening an authorization popup.

Use the Default organization filter to match any part of a listed organization name, without regard to case. The filter does not change the selected organization until you choose an option; a no-match result is different from an empty or failed organization list.

The form does not ask for App ID or installation ID. The default organization is only for Demo Provisioning; it does not affect Domain repository selection. Install the App into each required organization or personal account from the Domain repository screen, where Vibedata records the selected installation automatically.

The callback URL shown on this screen is used by the normal user Connect GitHub flow. It is the only GitHub App redirect URL Vibedata requires. The client secret is exercised during that first user connection.

Ambient Demo Provisioning

When AUTH_ENABLED=false, this settings surface is intentionally non-actionable and normal GitHub access continues to use the operator's ambient gh CLI session. To provision demo data in that mode, first configure and save the GitHub App here with authentication enabled. Then set DEMO_GITHUB_ORG in the Ambient deployment to select the Demo Provisioning target organization. Repository creation still uses the configured GitHub App; this environment variable does not affect normal ambient GitHub access.

Required GitHub App repository permissions

Configure these exact repository permissions on the App:

Permission	Level	Used for
Administration	Write	Creating and deleting Demo repositories
Contents	Write	Clone, commit, and push
Metadata	Read	Repository and branch discovery
Pull requests	Write	Opening and updating pull requests
Secrets	Write	Configuring encrypted GitHub Actions secrets
Variables	Write	Configuring GitHub Actions variables
Workflows	Write	Creating or updating workflow files

Do not add Actions or Issues for Vibedata. Workflows: write controls workflow files; it is not permission to administer workflow runs.

When you change an App permission, GitHub requires each existing installation to approve the update. Until approval, a Domain can report an insufficient-permission failure even though the App registration itself shows the new permission.

How to rotate the client secret

1. Open GitHub.
2. Type the new value in Client secret.
3. Click Test configuration.
4. Choose Default organization.
5. Click Save.

If a secret is already saved, Client secret shows Leave blank to keep the stored secret. Leaving the field blank keeps the stored secret. Show secret inside the field reads back what you typed before saving; a stored secret is never shown.

The private key follows the same retention rule. Leave it blank during an update to retain the saved PEM, or paste a replacement key to rotate it. A pasted key shows as dots until Show private key reveals it, and it is masked again when you hide it.

How to test, save, or archive the provider

• Test configuration validates the exact App identity and all required repository permissions with Client ID + PEM, then lists available organizations without changing the provider.
• Save validates the selected Default organization again, then saves the provider and selection together. It does not replace the active provider when validation fails.
• Archive keeps the singleton provider row but prevents delegated use until it is reactivated.

If PEM parsing, App authentication, the returned Client ID, the required permission map, or the organization selection fails, the existing provider remains active. Vibedata shows the safe configuration error returned by the validation. If no organizations are listed, install the App into an organization, then test again. Vibedata names every missing permission in the error. Correct the App settings, approve the change on existing installations, and test again. If the client secret is wrong, the normal user Connect flow reports the code-exchange failure and creates no user connection.

How Vibedata writes GitHub Actions secrets

The GitHub API supports writing repository secrets even though it never returns their plaintext:

1. Vibedata gets the repository's Actions public key from GitHub.
2. Vibedata decodes the key as standard padded Base64 and encrypts the secret locally with a libsodium sealed box (crypto_box_seal).
3. Vibedata encodes the ciphertext as standard Base64 and sends encrypted_value plus GitHub's key_id to PUT /repos/{owner}/{repo}/actions/secrets/{name}.
4. GitHub stores the secret. Later API reads expose only metadata such as its name and timestamps, so Vibedata can determine whether a named secret exists but cannot retrieve its value.

Secret plaintext is never sent to GitHub unencrypted, logged in reconciliation output, or returned from Domain settings.

Syncing a Domain repository to GitHub Actions

On an Active Domain, Resources > Git repository shows one Sync to GitHub Actions button for every Data Platform type, DuckDB included. A table above it previews the exact variable and secret names Vibedata will write. Selecting the button overwrites those values after you confirm; it never writes CD_* values or other repository settings.

Every value is attempted, and the results table gives each one a Result:

Result	Meaning
Created	The variable or secret did not exist and now does.
Updated	It existed and now holds the current value.
Failed	GitHub rejected the write. Detail shows GitHub's own status and message.
Not captured	The Domain holds no value for it. Detail names the setting that supplies it; set it, then sync again.

A banner above the table gives the verdict: Succeeded (every value created or updated), Incomplete (at least one value Not captured, none failed), or Failed (at least one value failed). Each sync replaces the previous results. A sync never changes the Domain's readiness or lifecycle.

Platforms that need values Vibedata cannot read from the service credential show a CI identity form in the same row: the AWS role ARN for Redshift, the workload identity provider for BigQuery, and the Snowflake role. Fill it in and select Save CI identity; until then those values show Not captured.

A successful sync means the values were written. Vibedata does not check that your CI can sign in. Set up GitHub OIDC trust for the Domain's service identity on your data platform yourself (for Fabric, see Set up GitHub OIDC trust for Fabric), and grant that identity only the access CI needs. MotherDuck has no workload identity federation, so its sync writes the service token as a secret instead.

A repository installed before this change reads the older variable names until you re-run /install-ci in the repository or edit the *_VAR lines in .workflow/ci-config.yml. Vibedata does not delete the older values.

Set up GitHub OIDC trust for Fabric

A Fabric Domain's CI signs in to Azure from GitHub Actions as the Domain's CI service principal, using GitHub OIDC, so no secret is stored. Azure accepts the short-lived GitHub token only if its subject matches a federated credential on the service principal's app registration. After this, grant the service principal access in Fabric, see Grant the CI service principal access in Fabric.

Sign in with az login as an owner of that app first, then replace each <placeholder>.

APP_ID="<entra-app-client-id>"            # the CI service principal's appId (VD_CI_SPN_CLIENT_ID)
OWNER="<github-owner>"                    # for example jasonkhaihoang-org
REPO="<github-repo>"                      # for example fabric-lh-01
NAME="<credential-name-prefix>"           # for example fabric-lh-01

OWNER_ID=$(gh api "users/$OWNER" -q .id)
REPO_ID=$(gh api "repos/$OWNER/$REPO" -q .id)
SUB="repo:${OWNER}@${OWNER_ID}/${REPO}@${REPO_ID}"
echo "$SUB"

az ad app federated-credential create --id "$APP_ID" --parameters "{
  \"name\": \"${NAME}-pull-request\",
  \"issuer\": \"https://token.actions.githubusercontent.com\",
  \"subject\": \"${SUB}:pull_request\",
  \"audiences\": [\"api://AzureADTokenExchange\"]
}"

az ad app federated-credential create --id "$APP_ID" --parameters "{
  \"name\": \"${NAME}-main\",
  \"issuer\": \"https://token.actions.githubusercontent.com\",
  \"subject\": \"${SUB}:ref:refs/heads/main\",
  \"audiences\": [\"api://AzureADTokenExchange\"]
}"

az ad app federated-credential list --id "$APP_ID" --query "[].{name:name,subject:subject}" -o table

Credential	Purpose	Without it
Subject lookup (owner@id/repo@id)	New GitHub repositories send an immutable subject that includes the owner and repository IDs. The credential must use that form.	AADSTS700213 on every login
:pull_request	Lets the CI workflow sign in for every pull request gate, and lets cleanup sign in when a pull request closes.	All CI jobs fail at the Azure login step
:ref:refs/heads/main	Lets scheduled and manual workspace cleanup sign in. They run on main, not on a pull request. Not yet verified end to end.	The scheduled sweep of orphaned ephemeral workspaces cannot sign in

Run manual cleanups from main. A manual run from another branch sends a different subject that neither credential covers.

Repairing a Domain GitHub failure

If Domain readiness names the GitHub App:

1. Confirm the provider passes Test configuration and Save on this screen.
2. Open the App installation in GitHub and approve pending permissions.
3. Confirm the Domain repository is included in the installation's repository selection.
4. Return to the Domain and select Reconcile in Resources.
5. Reopen the Domain and confirm it remains Active.

Related

• Org Settings
• Identity Providers
• Profile Settings