CI/CD: GitHub → Cloud Run

Continuous integration and continuous deployment is the software assembly line: a code push triggers tests, builds a container, and ships it to Google Cloud Run, which runs web apps without teams managing servers. (docs.cloud.google.com) The simplest GitHub-to-Cloud Run setups now use GitHub Actions on the code side and Cloud Run on the hosting side, with Google documenting both direct Git-based continuous deployment and GitHub Actions-based workflows. Cloud Run’s current docs say a push to a chosen branch can trigger Cloud Build to build and deploy automatically, while Google’s GitHub Action can deploy either a container image or source code. (docs.cloud.google.com) (github.com) That split explains the examples circulating now. One path lets Cloud Run watch a repository and use Cloud Build under the hood; the other keeps the pipeline in GitHub Actions, where teams can add tests, approvals, and environment-specific steps before deployment. (docs.cloud.google.com) (cloud.google.com) Cloud Run can also build from source code instead of requiring a hand-built container. Google’s documentation says `gcloud run deploy --source` uses buildpacks and Cloud Build by default, stores the built image in Artifact Registry, and can detect the app’s language when there is no Dockerfile. (docs.cloud.google.com 1) (docs.cloud.google.com 2) That is why “one-prompt” or minimal-tool deployment demos are getting attention: they cut out Docker setup, separate build commands, and much of the glue code that small teams usually write first. Google’s buildpacks package source into a production-ready container image, and the deploy action returns the service URL so later workflow steps can run checks against the live service. (docs.cloud.google.com) (github.com) The production angle is less about novelty than about repeatability. Google’s 2023 GitHub Actions guide centers on declarative service YAML, reusable workflows, GitHub environments, and promotion across multiple projects, which are the pieces teams use to keep staging and production deploys consistent. (cloud.google.com) Security is part of the same push toward templates. Google’s examples and action documentation use Workload Identity Federation, which lets GitHub Actions authenticate to Google Cloud without storing long-lived service account keys in a repository. (cloud.google.com) (github.com) The permissions are still concrete and sometimes broad. Cloud Run’s current documentation lists roles including Artifact Registry Administrator, Cloud Build Editor, Cloud Run Developer, Service Account User, and Service Usage Admin for setup, while the build service account needs roles such as Cloud Run Admin and Service Account User. (docs.cloud.google.com) Google is also widening the menu of connectors around the same deployment target. The current Cloud Run docs say GitHub can be wired in through Cloud Build, while Developer Connect supports GitHub, GitLab, and Bitbucket, and Cloud Deploy can handle multi-environment delivery for teams that want a fuller release pipeline. (docs.cloud.google.com) So the appeal of the new GitHub-to-Cloud Run examples is straightforward: push code, let a small workflow build and authenticate, and get the same deployment path every time. The tools are familiar, the hosted runtime is managed, and the template does most of the remembering. (cloud.google.com) (docs.cloud.google.com)