Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To deploy only what changed from an Nx monorepo to Cloud Run, let Nx calculate the affected projects from a complete Git base/head range, build and publish only the corresponding container images, and let GitHub Actions authenticate to Google Cloud with Workload Identity Federation (WIF). Deploy each selected image by a traceable reference, then verify the immutable Cloud Run revision and digest.
This design separates four decisions that are often mixed together: which Nx tasks must run, which projects map to Cloud Run services, which identity may deploy, and which identity the running container uses. Keeping those boundaries explicit makes selective deployment faster without turning CI into a broad, long-lived cloud credential.
The deployment path at a glance
A reliable pipeline has distinct gates. First, Git history and Nx’s project graph determine the affected set. Next, required checks run for that set. Then the deployable projects are built into images and pushed to Artifact Registry. GitHub Actions exchanges its OIDC token for short-lived Google Cloud credentials through WIF. Finally, Cloud Run receives an image reference, creates a revision, and serves the digest resolved for that revision.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute- Select: check out enough history, establish the comparison commits, and run the affected targets.
- Build: map affected deployable projects to their container build definitions.
- Publish: push uniquely identifiable images to Artifact Registry.
- Authenticate: use a restricted WIF provider and a job-scoped identity token.
- Deploy: update only the intended Cloud Run services and verify revision, digest, region, and invocation policy.
The exact project-to-service mapping, build tool, environments, regions, tests, and rollback policy belong to your repository and Google Cloud configuration; Nx and Cloud Run do not infer them for you.
#1 Best Overall
Make Nx’s affected set trustworthy
Give Nx a real base and head
Nx uses Git to find changed files, then maps those files through the project graph to select affected projects and tasks. The comparison is only as good as the commits supplied to it. A shallow checkout can omit the merge base or changed files, producing an incorrect set or no usable set at all. Nx’s GitHub Actions guidance uses a full checkout and the nrwl/nx-set-shas@v5 action to establish the range. See Nx’s GitHub integration guidance and the affected command documentation.
In a GitHub Actions job, the essential setup is conceptually:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: nrwl/nx-set-shas@v5The checkout action and SHA-setting action must run before any nx affected command. If you choose another method, set NX_BASE and NX_HEAD to commits that represent the intended comparison, and confirm that both commits and their merge base exist locally.
Run the checks your deployment policy requires
An Nx example is npx nx affected -t lint test build. Treat that as a pattern, not a universal target list. Your CI policy should name the targets that must pass before deployment, such as linting, unit tests, integration tests, or a production build. Affected selection does not automatically mean every selected target is safe to deploy; target dependencies and release checks still need to be configured in the workspace.
A shared library, root configuration, lockfile, or other common dependency can affect many projects. Therefore, affected does not promise a small deployment set. Nx follows the dependency graph so that a change with broad impact is not accidentally omitted.
Choose project-based or task-based selection deliberately
Standard affected selection starts with affected projects and runs the requested targets for them. Nx also documents task-based selection when NX_LEGACY_AFFECTED=false. Task-level accuracy depends on correctly declared task inputs and target configuration. Use it only when those inputs describe the real factors that can change a task's result.
| Selection approach | What it selects | When it fits |
|---|---|---|
| Project-based affected | Projects reached through changed files and the project graph, then their requested targets | The usual choice when project dependencies and target boundaries are clear |
| Task-based affected | Tasks whose declared inputs are affected, with NX_LEGACY_AFFECTED=false |
Workspaces that maintain precise task-input definitions |
Affected calculation is independent of Nx Cloud. Remote caching and task distribution can be added later, but neither is required to determine the affected set. Keep selection logic understandable before adding acceleration features.
Map affected projects to Cloud Run images
Define the deployable boundary
Not every Nx project is a Cloud Run service. Create an explicit mapping from deployable project to service name, image path, region, and environment. Affected checks may include libraries and test-only projects; deployment should include only projects that produce a container intended for a Cloud Run service.
The generic deployment sources do not prescribe a monorepo layout or container builder. Your mapping might be represented in project metadata, a script, or a workflow matrix. Whatever mechanism you choose, make it deterministic and fail when an affected deployable project has no service mapping. Do not silently deploy every service merely because one shared package changed; instead, let the graph determine which services are genuinely affected and apply your own release policy for broad changes.
Build and publish to Artifact Registry
Build each selected image with the repository's supported container process and push it to Artifact Registry. Cloud Run's deployment documentation identifies Artifact Registry as Google's recommended image registry; follow the repository's project, location, and repository settings in your environment. The image URL must include the registry host, project, repository, image name, and tag or digest.
Use a unique, traceable publishing reference such as a commit SHA plus project name. A mutable tag can be convenient while publishing, but it should not be your only audit record. Capture the pushed digest and associate it with the Git commit, Nx project, workflow run, and Cloud Run service.
Understand what Cloud Run pins
Cloud Run states that “revisions are immutable.” When you deploy an image tag, Cloud Run resolves that tag to a digest; the resulting revision serves that digest even if the tag is later moved. The deployed revision and image digest are therefore the durable identity to record, not just the tag. See Cloud Run deployment documentation.
Cloud Run does not support container image layers larger than 9.9 GB for images deployed from Docker Hub or Artifact Registry remote repositories backed by an external registry. Keep layers below that product limit or publish the image in a supported way before attempting deployment.
Authenticate GitHub Actions with Workload Identity Federation
Establish a restricted trust relationship
GitHub Actions can present its OIDC identity to Google Cloud. A Workload Identity Pool provider validates that assertion, maps the claims you need, and applies an attribute condition. Restrict the condition to the GitHub organization or repository that is allowed to deploy; add a branch or other workflow restriction when appropriate. Google's deployment-pipeline guide shows an organization condition and an optional branch condition such as assertion.repository_owner=='ORG' && assertion.ref=='refs/heads/main'. See Google's WIF deployment-pipeline guide.
Do not use a default-branch condition for every workflow automatically. Pull-request validation, release tags, and production deployment may need different admitted identities. Write conditions for the workflows that should be able to deploy, and reject all others.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Grant the token permission only where needed
The GitHub job that requests the OIDC token needs id-token: write. Scope that permission to the deployment job rather than granting it to the whole workflow when possible. Keep repository contents and other permissions no broader than the job requires.
permissions:
contents: read
id-token: writeConfigure the authentication action with the full provider resource name. Provider setup and IAM grants can take up to five minutes to propagate; an initial authorization delay is expected and is not a reason to weaken the provider condition.
Pick direct federation or service-account impersonation
Direct federation lets a federated principal access a supported target resource without an intermediate service account. The authentication action prefers this model when the target accepts federated principals. If a resource requires OAuth access or ID tokens issued through a service account, grant the federated principal permission to impersonate a dedicated service account and use that service account for the operation. The action documentation describes both models and notes a maximum 10-minute lifetime for the resulting token with direct federation. See the authentication action documentation.
| Model | Credential path | Use when |
|---|---|---|
| Direct WIF | GitHub OIDC assertion to a federated principal, then access to a supported resource | The target resource supports federated principals and no service-account token is required |
| WIF with impersonation | GitHub OIDC assertion to a federated principal, then short-lived credentials for a dedicated service account | Compatibility or an API requires service-account OAuth access or ID tokens |
Separate deployer and runtime identities
The identity used by CI to deploy is not the identity used by the container while it runs. Combining them grants the application more authority than it needs and makes a compromised runtime a deployment threat.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Permissions for the deployer
For a typical Cloud Run deployment, Google lists these permissions: Cloud Run Developer (roles/run.developer) on the Cloud Run resource, Artifact Registry Reader (roles/artifactregistry.reader) on the image repository, and Service Account User (roles/iam.serviceAccountUser) on the service account configured as the Cloud Run service identity. Cross-project service accounts can require additional grants. See Cloud Run deployment requirements and Cloud Run IAM roles.
The deployer calls Cloud Run APIs, reads the image, and is allowed to attach the selected runtime identity. It should not receive broad project-owner access merely to make a workflow pass.
Permissions for the running service
Cloud Run's service identity is a user-managed service account recommended for least privilege. Grant it only the Google Cloud permissions the application needs, such as access to a particular datastore, bucket, or messaging resource. It does not need CI deployment permissions. See Cloud Run service identity security guidance and service identity configuration.
| Identity | Primary responsibility | Typical scope |
|---|---|---|
| GitHub federated deployer | Authenticate the workflow and call deployment APIs | Restricted provider claims; Cloud Run, image-read, and service-account attachment permissions |
| Cloud Run runtime service account | Allow the application to call required Google Cloud APIs | Application-specific roles only |
Deploy and verify each selected service
Use an explicit image and service
The documented command shape is:
gcloud run deploy SERVICE --image IMAGE_URLAdd the intended region, project, runtime service account, and any environment-specific settings through your workflow's configured flags or service configuration. Ensure the service name comes from the affected-project mapping, not from untrusted pull-request input.
Decide invocation access explicitly. A public service grants the Cloud Run Invoker role to allUsers; an authenticated service requires callers to present an identity with invoke permission. This is a product and security decision, not an incidental deployment default. Document which services are public and which are IAM-authenticated, and review that choice when promoting between environments.
Verify the resulting revision
After deployment, capture the service, region, revision name, image digest, and traffic assignment. Confirm that the revision's digest matches the image digest produced by the build job. Then run application-level smoke checks appropriate to the service: health endpoints, authenticated requests, queue processing, or another deterministic check. A successful Cloud Run API call proves deployment, not that the application is healthy.
A practical workflow sequence
The following sequence keeps selection, checks, publishing, authentication, and deployment separate. Adapt names and commands to the repository rather than copying them as a complete universal workflow.
- Checkout: use
fetch-depth: 0or otherwise fetch the commits required for the comparison. - Set SHAs: run
nrwl/nx-set-shas@v5, or export a verifiedNX_BASEandNX_HEAD. - Install: install the lockfile-defined dependencies with the repository's package-manager command.
- Check: run the required affected targets, for example
npx nx affected -t lint test build. - Resolve services: derive the deployable project list from the affected result and the explicit project-to-service mapping.
- Build images: build one image per selected service and tag it with a traceable commit-oriented value.
- Authenticate: grant only the deployment job
id-token: write, then invoke the Google authentication action with the WIF provider resource. - Publish: push images to Artifact Registry and record each resulting digest.
- Deploy: run
gcloud run deployfor each selected service in its intended region, attaching the runtime service account. - Verify: inspect the new revision and digest, validate traffic and invocation policy, and run smoke checks.
Troubleshoot the common failure modes
Nx reports no affected projects or an unexpectedly large set
- Check that the checkout contains the base, head, and merge-base commits; shallow history is the usual cause of unusable comparisons.
- Print and review
NX_BASEandNX_HEADin the job logs without exposing secrets. - Confirm that the event type maps to the intended comparison, especially for merge queues, pull requests, and release branches.
- Inspect project-graph dependencies: a shared package or root configuration can legitimately expand the set.
- Verify target inputs before enabling task-based affected selection.
Authentication is denied
- Confirm the job has
id-token: writeand that the authentication action references the exact provider resource. - Compare the token's repository owner, repository, ref, and event claims with the provider attribute condition.
- Check that federated-principal or service-account-impersonation grants are on the intended resource.
- Wait for IAM and provider changes to propagate for up to five minutes before changing policy.
- Keep conditions restrictive; do not solve a mismatch by admitting every repository or branch.
Cloud Run cannot pull or start the image
- Verify the deployer can read the Artifact Registry repository and that the image URL uses the correct project and location.
- Check that no image layer exceeds the 9.9 GB Cloud Run limit for the affected registry path.
- Confirm the revision uses the expected digest and that the container listens on the port and runtime contract required by the service.
- Separate image-pull permissions from runtime API permissions; granting the runtime service account extra deployment roles will not fix a missing deployer grant.
Pre-deployment checklist
- Base and head commits are explicit, present locally, and appropriate for the triggering event.
- Affected targets include every check required by the release policy.
- Project-to-service mapping is deterministic and excludes non-deployable Nx projects.
- Images are published to Artifact Registry with a traceable tag and recorded digest.
- WIF conditions restrict organization, repository, and branch or event as intended.
- Only the deployment job can mint the GitHub OIDC token.
- Deployer and runtime service accounts are separate and minimally privileged.
- Cloud Run region, service identity, and public or authenticated invocation are explicit.
- The resulting revision, digest, traffic assignment, and smoke-check result are recorded.
The Bottom Line
Selective Nx-to-Cloud Run deployment is safe when Git history makes the affected set reliable, service mapping is explicit, WIF trust is narrowly conditioned, deployer and runtime identities are separate, and every deployment is verified by its immutable revision and image digest.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
