Janitor Start with GitHub

Your part ends at the merge.

Janitor is a delivery agent for GitHub repositories. Connect one and it writes the pipeline, signs every build, deploys to production and repairs what fails.

Start with GitHub See how it works

An example run: every stage passed.

How it works

Review the pipeline and set up its delivery foundation before merging. After that, commits on your delivery branch follow the delivery path you configured.

A Google Cloud project owner reviews and runs the access commands. Janitor then applies the delivery foundation and shows its progress. Cloud setup itself does not deploy your application.

  1. Sign in with GitHub

    The console signs you in with your GitHub account.

  2. Install Janitor on a repository

    Janitor reads it and finds the services, where they run, and what is already running there. No Dockerfile needed.

  3. Review one pull request

    It holds the configuration, workflows, Cloud Run manifests and delivery Terraform. Review it and complete cloud setup before merging.

  4. Merge

    Wait for the foundation and current checks to pass. That commit starts the first delivery.

After the merge, the line is Janitor’s.

One file holds the configuration

A repository’s delivery configuration is one file, janitor.config.yaml. There are three ways to arrive at it, and each ends in that file through a pull request.

  • Discovered

    Janitor reads the repository and proposes the whole configuration.

  • Edited in the console

    A configuration editor shows it as a form and as YAML. Saving opens a pull request.

  • Committed by hand

    Change the file in your own pull request, and Janitor commits the generated pipeline that follows from it onto that branch.

janitor.config.yaml

through a pull request

Only a pull request crosses the boundary

Janitor runs a software delivery clean room. Source and tests enter through a pull request. From the merge commit onward, Janitor generates, observes and repairs everything.

You provide

  • Code and tests, in a pull request
  • janitor.config.yaml, when the shape of delivery should change
  • A decision to promote, when an environment is manual

Janitor owns

  • Pull-request checks
  • GitHub Actions workflows, written and kept current
  • Cloud Run manifests
  • Terraform for delivery infrastructure
  • Builds, signed provenance, deployments and releases
  • Re-runs, diagnosis, fixes, promotions and rollbacks

Pipelines run on GitHub Actions, the runners and UI you already know. Janitor writes the workflows and keeps them current. Nobody hand-edits workflow YAML.

One commit, one version, one run

Every commit on the delivery branch is one version. One run carries it along a fixed path.

  1. Check

    Runs the tests again on the merge commit, on the delivery branch itself.

  2. Build

    Builds an image for each service. Images whose inputs did not change are reused, so unchanged services do not slow a release down.

  3. Attest

    Signs SLSA v1.0 Build Level 3 provenance for every image.

  4. dev

    Verifies the provenance, then deploys to dev.

  5. prod

    Verifies it again, then deploys the same images to prod.

  6. Release

    A version that reaches the last environment becomes a GitHub release.

How a stage reads

  • passed
  • running
  • waiting
  • failed
  • skipped

When a run fails

  • A run fails at Build.
  • Janitor re-runs it once, on its own.
A first failure
Re-run once, automatically. A failure that repeats is diagnosed instead of retried.
A real failure
Diagnosed from the job logs and explained in a sentence. Janitor can open the fix as a pull request.
A rollback
The same operation as a promotion: an existing version is deployed through the same verification.

No provenance, no deployment

  • A signed image is verified, then deployed.
  • An image without provenance stops at the valve.
What is signed
Every image, with SLSA v1.0 Build Level 3 provenance.
What builds it
A trusted builder workflow on GitHub-hosted runners.
What signs it
A Cloud KMS key that only the attest workflow on the protected branch can use.
What refuses
Every deployment, promotions and rollbacks included: it verifies the provenance first and refuses an image without it.

Read the guarantee and its limits in the docs

Where it delivers

Services and static sites go to Google Cloud Run. Mobile apps go to the stores in the same run, as one signed build per version.

  • Google Cloud Run

    Services and static sites. Each environment runs a generated manifest pinned to the verified image.

    Available today

  • App Store

    iOS apps, to TestFlight and then the App Store.

    New in v1. Not yet proven on a live store account.

  • Google Play

    Android apps, to a testing track and then production.

    New in v1. Not yet proven on a live store account.

Pipelines run on GitHub Actions. Delivery infrastructure is generated Terraform. The agent is a Gemini model running on Google Cloud Run.

A conversation on the left, a live view on the right

Ask in plain words and the view follows. It is organised by org, repository, version, environment and checks, and it condenses a whole pipeline into one line instead of scattering it across GitHub tabs.

Use the conversation for delivery requests, or choose Set up Google Cloud on a repository for access instructions and foundation progress. Cloud setup does not deploy the application.

Access follows GitHub: you see only the repositories you can read there, and can operate only those you can push to.

A schematic with example data, not a screenshot.

Connect a repository and read the pull request it opens.

Start with GitHub

Janitor delivers itself. This page reached you along the same path: checked, built, signed, verified and deployed from its own repository.