Darshil Explains: Building a Tag-Based CI/CD Pipeline on Google Cloud

Developing the Medas sepsis and diagnosis frontend

[0:00]Jambo, this is Darill developers push code to meta's aggregation front end. The front end for an AI assisted diagnostic tool doctors used to review sepsis and diagnosis output. Here's everything that had to exist before a push could become a running service, the GCP trust chain, the app itself, and how

Creating the Artifact Registry repository on GCP

[0:16]It all actually gets shipped. Start with somewhere for a built image to live. Create a dedicated artifact registry repository for the front end in the same GCP project and region. The back end already uses project meta's 499,121

Sharing Workload Identity Federation pools across backend and frontend repositories

[0:32]Region assist one. Now the identity path the backend already has a workload identity federation pool set up. No reason to build a second one. List what's there GitHub pool and inside it GitHub provider. The provider currently trusts only the backends repo. Widen its attribute condition to also accept this

Configuring GitHub dev environment secrets and variables

[0:51]One. So both repos can authenticate through the same door. The provider recognizes the repo. The service account still has to agree to be impersonated by it. Bind the shared GitHub actions service account. So this repo's workload identity can act as it one role scoped

Overview of the React & Vite doctor-facing diagnosis component interface

[1:06]To exactly this repository. On the GitHub side, a new environment named dev holding two secrets and seven variables. Neither secret is a longived credential, just the provider path and the service account email. The variables assemble

Tag-based deployment triggers vs. building on every commit

[1:20]The image tag and point the deploy at the right project region and service. Put together that's the whole trust chain. The front-end repo requests a token. The provider recognizes it. The shared service account accepts the impersonation and its existing GCP roles

Writing a two-stage Dockerfile using Node and Nginx

[1:36]Carry it the rest of the way into artifact registry in cloud run. Before the pipeline, the thing the pipeline ships a vite and react front end for doctors reviewing AI assisted sepsis and diagnosis output. Ogates the app. No token, no diagnostic view. Everything

Building, pushing, and deploying to Cloud Run

[1:51]Doctor facing lives under components. Diagnosis editing. Sepsis panels and output table. A dialogue thread. A mic button for voice input. Trust chain ready. The app ready to ship. But nothing tied a code changed to a running service. Every deploy was a manual build

Setting explicit IAM bindings for doctor access

[2:06]On someone's machine. The plan. A tagbased CI/CD pipeline. Push a tag and a container gets built, pushed into the registry already set up and deployed straight to Cloud Run. First design decision. No deploy on every commit. Only a tag dev, stage v, or a bare v for

The developer workflow: Git tag and push

[2:22]Master triggers a build. Tagging is the moment someone decides this commit is promotable, not the moment it was written. The container is two stages. Node builds the vite app. The API URL and version get baked in as build arguments because vite inlines them into the bundle at build time, not read at container runtime. Then a clean enginex image serves only the built disc folder. None of the node tool chain ships in the final image. The workflow authenticates with the identity set up earlier, builds the image with the variables from the dev environment, pushes it to the artifact registry repo created earlier, then deploys it as a new cloud run revision using the same service account the whole way through. End to end tag authenticate, build, push, deploy. One more step lives outside the workflow file. Some org policies block

Public access even with allow an authenticated set. So the cloud run service itself needed an explicit AM binding for all users before doctors could actually reach it. So here's what exists now that didn't before. A shared trust path the front end borrows from the backend instead of duplicating. A two-stage container that ships nothing but static files and engine X and one tagging convention that decides dev stage or master. A developer's whole deploy action after all of this is two lines. Get tag get push. Your turn. If your team already has one repo deploying to GCP through workload identity, don't stand up a second identity path for the next one. Widen the existing provider's condition. Bind the new repos principle to the shared service account and reuse everything else, the registry, the roles, the workflow shape. Push taglive. This is Darel.