Skip to main content

Connecting Existing Repos, DNS, Auth & Other Common Configs

Setting Up a GitHub Repository & CI walks through creating a brand-new repository from scratch. Most teams adopting Infrastream aren't starting from zero — they already have a repo, a domain, and an auth story. This guide covers the five things that come up right after initial onboarding: connecting a repository you already have, wiring up its CI/CD, pointing a domain at it, adding authentication, and a few other configs teams commonly reach for next.

1. Connecting an Existing GitHub Repository​

You don't need a separate "import" flow. Declaring a GithubRepository manifest whose name matches your existing repository causes the engine to adopt it instead of creating a new one — the executor looks the repository up before ever attempting to create it, and only creates when nothing is found.

apiVersion: lowops.manifests.v1
kind: GithubRepository
metadata:
  name: legacy-billing-service  # Must match the existing repo's name on GitHub
  organization: fincorp
spec:
  strategy: GITHUB_FLOW
  codeOwners:
    - path: "*"
      owners:
        - platform-team
  permissions:
    administrators:
      groups:
        - platform-admins
    contributors:
      groups:
        - backend-team

Once merged, the platform applies your declared branch protection, CODEOWNERS, and permissions on top of the existing repository — it does not touch existing history, issues, or settings outside what the manifest declares.

Prerequisite: Grant the GitHub App Access​

If your organization's GithubConnection has its GitHub App installation scoped to "Only select repositories" rather than "All repositories," adoption will fail to find a repo the app hasn't been granted access to. When that happens, the engine falls through to the create path and GitHub rejects it with a "name already exists" conflict — since the repository is real, just invisible to the app.

Before merging your GithubRepository manifest for an existing repo:

  1. Go to your GitHub organization's Settings → Applications → Installed GitHub Apps.
  2. Find the Infrastream GitHub App installation and select Configure.
  3. Under Repository access, add the existing repository to the selected list (or switch to "All repositories" if that fits your org's policy).

2. Wiring Up CI/CD for It​

Once the repository is connected, adding CI/CD is identical to the new-repo flow — see Setting Up a GitHub Repository & CI for the full BuildDefinition walkthrough. One ordering detail that guide doesn't call out:

ArtifactRegistry must already exist before a BuildDefinition references it. The containerize.registries field (and each language block's registry field) is validated against already-declared ArtifactRegistry or ExternalRegistry manifests by name — referencing one that doesn't exist yet fails validation with an "unknown artifact/external registry" error. If you don't already have a registry for this service, declare it first:

apiVersion: lowops.manifests.v1
kind: ArtifactRegistry
metadata:
  name: fincorp-docker-registry
  organization: fincorp
spec:
  type: DOCKER
  region: us-central1
  permissions:
    writers:
      groups:
        - backend-team

Commit the ArtifactRegistry in the same PR as (or an earlier PR than) the BuildDefinition that references it.

3. DNS for a Custom Domain​

If this service needs a custom domain rather than the platform's auto-generated FQDN, that's covered end-to-end in Setting Up Custom Domains. The short version: PublicIngress.spec.domain.name provisions a dedicated Cloud DNS zone for the domain, and the one manual step is delegating the domain to that zone via NS records at your registrar — not creating an A record. See that guide's Step 6 for the exact procedure.

4. Authentication​

Infrastream has two independent auth mechanisms, and it's worth being clear about which one you need:

  • End-user login (GCIP) — for applications with their own sign-in page (customers, external users). Declare an IdentityProvider manifest and reference its name from an HttpRoute/GrpcRoute rule's authentication block:

    apiVersion: lowops.manifests.v1
    kind: IdentityProvider
    metadata:
      name: billing-portal-login
      project: payment-gateway
      environment: production
      organizational-unit: retail-banking
      organization: fincorp
    spec:
      displayName: "Fincorp Billing Portal"
      logoUrl: "https://fincorp.com/logo.png"
      iconUrl: "https://fincorp.com/icon.png"
      providers:
        google: true
    # In the HttpRoute rule for the protected path:
    rules:
      - matches:
          - prefixMatch: /portal
        action:
          destinations:
            - deploymentConfig: billing-portal
              port: 8080
        authentication:
          - type: IDENTITY_PROVIDER
            tenants:
              - billing-portal-login

  • Internal access (IAP) — for staff-only tooling behind a PublicIngress, no per-user login page. Set type: INTERNAL on the route rule instead, and grant access via the ingress's iapPermissions:

    rules:
      - matches:
          - prefixMatch: /admin
        action:
          destinations:
            - deploymentConfig: billing-admin
              port: 8080
        authentication:
          - type: INTERNAL

    Access is then controlled by the iapPermissions block on the parent PublicIngress manifest (see Setting Up Custom Domains for that field).

WorkforceIdentityProvider is not yet functional

You may notice a WorkforceIdentityProvider manifest kind in the schema — don't reach for it. It's a declared no-op today: no defaulter, validator, or executor reads its spec. Workforce/staff SSO federation (e.g. Entra ID) is configured at the Organization level by the platform team, not per-application. If you need staff SSO for internal tooling, use IAP (type: INTERNAL) as shown above, or talk to your platform team about Organization-level workforce federation.

5. Other Common Configs​

A few more manifest kinds teams typically set up shortly after initial onboarding:

  • GithubSecret — makes a credential available to your repository's GitHub Actions workflows (e.g. an npm token or a third-party API key needed at build time, as opposed to runtime app secrets). Either inline or backed by an existing Secret:

    apiVersion: lowops.manifests.v1
    kind: GithubSecret
    metadata:
      name: npm-publish-token
      organization: fincorp
    spec:
      valueRef: npm-publish-token-secret  # Name of an existing Secret manifest

    Reference it by name in your repository's spec.secrets list (see Setting Up a GitHub Repository & CI).

  • ExternalApplication + ExternalRegistry + TrustedRepository — for deploying an image that's already built somewhere else (Docker Hub, a legacy CI system) instead of going through Infrastream's own BuildDefinition pipeline. Declare an ExternalRegistry for the source, a TrustedRepository marking it as trusted, and an ExternalApplication referencing both — it provisions the same identity, networking, and mesh structures as a native Application, just sourced from outside the workspace.

Monitoring and Alerting are schema-only today

Monitoring and Alerting manifests exist in the schema but are currently inert — no executor reads their spec, so applying them provisions nothing. Don't rely on them yet; they're intended future functionality, not a working feature.