ci: add import profiler check across monorepo

[hebaalazzeh]

Overview

This PR integrates the import profiler script (introduced in #17467) into our automated CI pipeline.

Why this matters: Import times significantly impact CLI responsiveness and cold starts for Serverless products like Cloud Run and Cloud Functions. Ideally, library imports should stay under 500ms, and anything taking over 1 second is a target for optimization. This CI check helps us proactively track metrics like import latency, memory footprint, and code volume to prevent performance regressions on critical libraries.

The primary goal of this check is to track and enforce performance standards for package import times across the repository, especially following our recent work on lazy loading and cold-start optimizations.

By running this benchmark as a CI check with a defined dynamic differential failure threshold, we can programmatically prevent latency regressions in module initialization times before they are merged, ensuring downstream consumers aren't impacted by unexpectedly slow startup times.

Changes Included

• GitHub Actions Workflow: Created a new workflow (.github/workflows/import-profiler.yml) that triggers on PRs and merge groups. The workflow is pinned specifically to Python 3.15.
• Native CI Integration (No template bloat): Rather than polluting the central gapic-generator template (noxfile.py.j2) and forcing updates across 150+ packages, the CI script (ci/run_single_test.sh) natively handles the profiler. It automatically spins up a lightweight virtual environment, installs the target package, and runs the profiler.
• Dynamic Differential Checks: Enhanced ci/run_single_test.sh to checkout HEAD^1 (the main branch), generate a baseline CSV profile, and then diff it against the PR branch. If the P99 import time of the PR degrades by >100ms compared to the baseline, the CI check will fail.
• Safety Backstop: The script still enforces an absolute hard-failure backstop of 5000ms for extreme regressions.
• Conditional Execution & Graceful Skips: The pipeline verifies if a valid setup.py exists before attempting to profile, gracefully skipping directories that are not valid Python packages.
• All Packages Testing: Adding the import_profile:all_packages label to a Pull Request will force the CI pipeline to run the profiler check against all packages in the mono-repo, instead of just the modified ones.

Developer Interactions

If a developer fails this CI check due to an import latency regression, they can reproduce and debug it locally by running the profiler script with the --cprofile flag (python scripts/import_profiler/profiler.py --package <their-package> --cprofile). This will generate a cProfile stack trace breakdown of the import time, allowing them to pinpoint exactly which new dependency or module initialization is causing the latency spike.

Related PRs

Builds upon the import profiler tool added in #17467

[gemini-code-assist]

Code Review

This pull request adds a new import_profile session to the noxfile.py.j2 template to measure and ensure import times remain below defined thresholds. Feedback points out that because this template is used in standalone repositories outside of the monorepo, referencing a relative path to the monorepo's root scripts directory will cause default nox runs to fail in those environments. It is recommended to check for the script's existence and gracefully skip the session if it is missing, while also using pathlib.Path for cleaner path handling.

[daniel-sanche]

I left a couple comments. It would be good to clarify the goal of this check though.

What counts as a failure? Can we calculate an import time diff before and after the target changes, instead of just reporting an absolute value? How are developers intended to interact with this?

[daniel-sanche]

This PR doesn't touch any packages, so it's hard to tell what the action will look like. Can you temporarily touch some files to test it out?

[daniel-sanche]

We should also see how long the new check would take if all packages were updated. In #17438, I added a new unit_test:all_packages tag, that will run against all packages when added. Maybe we should support that here too

It's possible we would only want to profile a few key packages instead of all of them. Most generated libraries should be very similar

[hebaalazzeh]

addressed!

[hebaalazzeh]

/gemini