fix: skip GCP-authenticated CI checks for fork PRs

[zeroasterisk]

Problem

All pull requests from forks currently fail CI with this error:

google-github-actions/auth failed with: GitHub Actions did not inject
$ACTIONS_ID_TOKEN_REQUEST_TOKEN or $ACTIONS_ID_TOKEN_REQUEST_URL into
this job. This most likely means the GitHub Actions workflow permissions
are incorrect, or this job is being run from a fork.

Root Cause

The checks workflow (test_templated_agent.yaml) uses Workload Identity Federation via google-github-actions/auth@v3 to authenticate to GCP project adk-devops. It then pulls a private Docker container from Artifact Registry (europe-west4-docker.pkg.dev/production-ai-template/starter-pack/e2e-tests) to run the lint and test steps.

This authentication requires an OIDC identity token (id-token: write permission), which GitHub Actions only provides to workflow runs from branches within the same repository. For security reasons, GitHub does not inject OIDC tokens into workflows triggered by fork PRs. This is by design — it prevents fork PRs from accessing repository secrets or impersonating the repo's identity.

Impact

Every external contributor's PR fails CI, including:

• Community contributors who fork and submit PRs
• University capstone students adding Agent Starter Pack templates (e.g., PRs feat(youtube-analyst): add Agent Starter Pack support #1284, Feat/short movie agents agent starter pack #1285, feat: add agent starter pack. #1286, Add ASP as primary setup in academic-research agent #1226, Add starter pack to CAMEL agent #1228, Add Agent Starter pack to Data Science agent. #1229, Add ASP as primary setup, bump version, reorganize README #1232, Add Agent Starter pack to Plumber DE Assistant agent #1233, Travel-concierge-asp [ASP as primary setup, bump version, reorganize README] #1240)

The failures are not due to code quality issues — the code never gets a chance to be linted or tested. Contributors see a red ❌ with a cryptic GCP auth error, which is confusing and discouraging.

Note: The ruff-checks.yml workflow is not affected — it only uses GITHUB_TOKEN (which works fine on forks) and continues to provide lint feedback on all PRs.

What This PR Does

1. Detects fork PRs in the discover-changed-agents job by comparing github.event.pull_request.head.repo.full_name against github.repository
2. Skips the GCP-authenticated test-agent-template job when the PR comes from a fork (via an if condition)
3. Adds a fork-pr-notice job that runs instead, printing a clear message explaining why the GCP checks were skipped

What Contributors See After This Change

• Fork PRs: Ruff Format & Lint Suggestions ✅ runs normally, Fork PR Notice ✅ explains the situation, GCP checks are cleanly skipped (no red ❌)
• Same-repo PRs: No change — all checks run as before with full GCP auth

Security Consideration

This PR does not expose any secrets or credentials to fork PRs. It simply prevents the workflow from attempting (and failing) to authenticate. The OIDC tokens and GCP credentials remain inaccessible to forks.

A maintainer can always re-run the full CI suite by pushing the fork's changes to a branch within this repository if GCP-authenticated testing is needed before merge.

Alternative Approaches Considered

1. Add contributors with write access — works but doesn't scale for open-source contributions
2. Use pull_request_target trigger — would give forks access to secrets, which is a known security anti-pattern (see GitHub docs)
3. Run GCP checks post-merge — delays feedback too long

The approach in this PR (skip + notify) is the standard pattern used across Google open-source projects and is the safest option.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

There is a problem with the Gemini CLI PR review. Please check the action logs for details.