GitHub integration

Galinum can activate prepared communications after GitHub reports successful production deployment of their associated changes. The product server supports this workflow on self-hosted installations with your own GitHub App. Hosted automatic drafting is not required.

​

Prepare a communication

Use ordinary campaign POST/PATCH to write content and its sourceChanges together. Declare direct commits or PR bundles from configured project sources. Create accepts { changes }; replacement PATCH requires { expectedRevision, changes } from the current campaign detail projection. Omitting sourceChanges preserves the declaration and approval. Content and associations commit atomically. Source edits retain approval, but automatic launch must cover the current declaration. Source-managed preparations cannot replace associations through the generic field. Such a request returns 409 before changing copy; use that preparation’s existing source workflow.

​

Configure tracking and review

For the stock server, follow self-hosted activation setup. An authorized operator registers sources, confirms each deployment scope, and approves a current content/source review through separate operator HTTP controls. Agent management credentials and MCP tools cannot configure scope or approve. Operator authority is an administrative delegation; it does not prove that a human personally made each HTTP request. Select the exact repository, production environment, and sources that each deployment ships. Describe the scope and explicitly confirm it. One repository does not necessarily represent one deployed application. An agent cannot infer this configuration or confirm it with its management credential. GitHub App deployment tracking needs Deployments: read-only, plus read access to repository contents and pull requests for source evidence. Accept requested permission updates for existing installations. Polling works without webhooks. Where signed webhook ingress is configured, Deployment status (deployment_status) events can wake work sooner; they never grant coverage. Projects initially use automatic launch. Change the project default or set an individual campaign to automatic or manual. A null campaign override inherits the project default. Default changes affect every unlaunched campaign without an explicit override; explicit overrides stay unchanged. Saving tracking also evaluates existing approved drafts. Eligible automatic drafts can launch without another approval or deployment. Select manual mode before setup for communications you want to launch yourself.

​

Automatic launch

Automatic launch requires approval and current deployment coverage for every associated change across all required repository/environment mappings. A missing or unclear mapping prevents automatic launch. Drafting and grouping remain available when mapping is unclear. If deployment succeeds before approval, later approval makes the communication eligible while its changes remain deployed. Source revisions retain approval. Automatic launch uses the latest content and checks its current associated changes, rather than the changes present when you approved it. Project and source pause controls, withdrawn or unresolved sources, and delivery expiry still apply. Current channel readiness must succeed when launch commits. Missing or failed readiness blocks launch; a previous check does not authorize it. A future deliverFrom permits activation but delays delivery until that window opens. An expired deliverUntil blocks activation. The activation API and campaign supervision panel show the effective mode, approval, waiting reasons, coverage for each mapping, last check, launch evidence, and warnings. The management API exposes this state through GET /api/v1/campaigns/{id}/activation and the default through GET /api/v1/launch-policy. Revision-checked PATCH requests change these modes; they do not approve campaigns or configure deployment scope.

​

Launch manually

Use manual mode for feature flags, gradual rollouts, and unclear deployment mappings. Select Launch when the intended audience has access. Manual launch uses the existing readiness and lifecycle checks without requiring GitHub deployment coverage. No deployment integration is required for manual launch.

​

Deployment evidence and retries

Only successful deployments in the configured repository and exact environment can establish new coverage. Pending, failed, and unselected-environment deployments cannot. A newer failed or pending deployment does not erase previously deployed code. A later invalidating status on the selected deployment leaves evidence unknown; Galinum does not fall back to a superseded success. GitHub reports deployment status; it does not independently inspect your running application. Galinum checks direct commit ancestry and complete merged PR bundles, including merge, squash, and rebase results. All required changes must be covered. Git history alone does not prove that a feature is available to its audience. Evidence reads have bounded page, request, and byte limits. Missing history, ambiguous source identity, incomplete comparisons, stale provider responses, and provider failures leave evidence unresolved. They never count as successful coverage or proof of rollback. Periodic reconciliation retries pending work, including missed signals and temporary failures. Duplicate, delayed, out-of-order, and concurrent signals do not duplicate initial launch or restore stale evidence. Already started, paused, or ended campaigns never restart from replayed signals.

​

Rollbacks and reverts

An explicit rollback that excludes required changes, or a deployed identifiable revert, invalidates coverage for an unlaunched communication. Detection uses Git/deployment evidence and canonical full-SHA revert declarations. A causal revert of a revert can restore coverage; unrelated reverts do not cancel each other. Ambiguous or incomplete history remains unknown. Galinum does not ask an agent to infer feature removal from arbitrary code edits. If the communication already launched, including a manual launch, deterministic coverage loss creates a warning on the communication and in the agent activity feed. Warnings identify the affected changes and deployment evidence. They do not automatically pause delivery, change its window, or send email. You decide whether to pause the communication. Later relevant source changes can still produce another unlaunched draft.

​

Hosted source drafting

Galinum Cloud can also prepare communications from connected repositories. This hosted source-job workflow is separate from the product activation workflow. The stock self-host server does not perform hosted automatic drafting. In Settings → GitHub, connect your GitHub account, install the Galinum GitHub App, select a repository and target branch, and add project instructions. Pushes cover direct commits and merged PRs. Drafting starts from the branch’s current state; it does not announce the repository’s full history. Enable Draft from ready pull requests for early preparation. A non-draft PR becomes eligible when opened or marked ready. Returning it to draft pauses updates; closing without merge withdraws its contribution. Merge reconciliation reuses the early draft rather than creating a duplicate. The agent groups relevant changes into unlaunched campaigns and skips changes without customer value. Source work cannot approve or launch its own draft. Review the content and GitHub sources in the campaign. Approval can make an automatic campaign eligible when its current changes are already deployed. Use the campaign’s revision prompt with your authenticated agent to request copy changes. Relevant source updates can still revise a customer-edited draft, preserving unrelated changes and existing approval. Refresh the preview to inspect the latest content. Already launched campaigns are not revised by source drafting; later changes can produce another draft.