Skip to main content

Setting Up a GitHub Repository & CI

This guide walks you through the complete process of creating a managed GitHub repository with fully automated CI pipelines, branch protection, and container publishing — all from declarative YAML.

This is one of the core IDP capabilities of Infrastream. By defining a GithubRepository and a BuildDefinition, the platform will:

  • Create the repository with the correct visibility, license, and CODEOWNERS
  • Apply branch protection rules matching your chosen branching strategy
  • Auto-generate GitHub Actions CI workflows for building, testing, and containerizing your application
  • Publish images to Artifact Registry with Binary Authorization attestations

Prerequisites​

  • You must have an existing Organization and GithubConnection manifest configured (these are set up by the platform team).
  • You need an ArtifactRegistry manifest in your project to publish container images to.

Step 1: Define Your GithubRepository Manifest​

Create a YAML file for your repository:

apiVersion: lowops.manifests.v1
kind: GithubRepository
metadata:
  name: payment-api
  organization: fincorp
spec:
  description: "Backend API service for payment processing"
  strategy: GITHUB_FLOW            # GITHUB_FLOW | GIT_FLOW | TRUNK_BASED
  template: go-service-template    # Optional: seed from a GithubRepositoryTemplate
  license: mit-license             # Optional: name of a GithubLicense manifest
  codeOwners:
    - path: "*"
      owners:
        - platform-team
    - path: "manifests/**"
      owners:
        - platform-team
        - devops-team
  permissions:
    administrators:
      groups:
        - platform-admins
    contributors:
      groups:
        - backend-team
    viewers:
      groups:
        - engineering
  configuration:
    issues: true
    projects: false
    wiki: false
    downloads: false
  secrets:
    - sonar-token                  # GithubSecret manifests to make available
  aiAssistant:
    pullRequest:
      enabled: true                # Enable AI-assisted PR descriptions

Key fields:

  • strategy — Determines branch protection rules, versioning behavior, and merge policies. See the Internal Developer Platform guide for details on each strategy.
  • template — Seeds the repository from a GithubRepositoryTemplate manifest.
  • codeOwners — Generates the .github/CODEOWNERS file. This is critical for HPAM governance.

Step 2: Define Your BuildDefinition Manifest​

Create a YAML file that defines how to build and containerize your application:

apiVersion: lowops.manifests.v1
kind: BuildDefinition
metadata:
  name: payment-api
  organization: fincorp
spec:
  description: "CI pipeline for the payment API (Go backend)"
  type: GOLANG                     # GOLANG | JAVA | PYTHON | FLUTTER | PROTOBUF | etc.
  stages:
    - test
    - containerize
  golang:
    buildType: bin                  # 'bin' for executable, 'lib' for library
    target: "./cmd/server"
    versions:
      - "1.23"
    platforms:
      goos:
        - linux
      goarch:
        - amd64
        - arm64
  containerize:
    - name: payment-api
      dockerfile: Dockerfile
      platforms:
        - linux/amd64
        - linux/arm64
      registries:
        - fincorp-docker-registry  # Name of an ArtifactRegistry manifest

Key fields:

  • type — The primary language/toolchain. Supported types: GOLANG, JAVA, PYTHON, FLUTTER, PROTOBUF, MOJO, HELM, TERRAFORM, VALIDATOR.
  • stages — The ordered list of CI stages. Common stages: test, containerize.
  • containerize — Defines one or more container images to build. Each entry specifies a Dockerfile, target platforms, and destination registries.

Note: The platform auto-generates SHA-pinned GitHub Actions workflows from this definition. You never write .github/workflows/*.yml manually. The generated workflows include Binary Authorization attestation, Workload Identity Federation authentication, and automatic version tagging based on Conventional Commits.

Step 3: Connect to an Application​

To deploy the built image, create an Application manifest that references the BuildDefinition:

apiVersion: lowops.manifests.v1
kind: Application
metadata:
  name: payment-api
  # ... project identity ...
spec:
  source: payment-api              # Name of the BuildDefinition manifest
  container: payment-api           # Name of the container within the BuildDefinition
  target: CLOUD_RUN                # CLOUD_RUN | GKE | COMPUTE
  project: payment-gateway

Step 4: Commit, Review, and Merge​

Commit all three manifests (GithubRepository, BuildDefinition, and Application) in a single pull request.

After merge, the platform will:

  1. Create the GitHub repository with the correct structure, protection rules, and CODEOWNERS.
  2. Generate and commit CI workflows to the repository's .github/workflows/ directory.
  3. On each push, CI will build, test, containerize, attest, and publish your image.
  4. The CD system will automatically deploy new versions through your ReleaseTrack.