[kikoso]

Stack

• perf: ship Baseline Profiles in maps-compose, maps-compose-utils and maps-compose-widgets #1063 perf: ship Baseline Profiles in maps-compose, maps-compose-utils and maps-compose-widgets (Base → main)
• 👉 This PR (Stacked → feat/baseline-profiles)

Summary

Baseline Profiles go stale as the code changes, and nobody will remember to regenerate them by hand. This adds a Regenerate Baseline Profiles workflow that runs the generator from #1063 on an emulator and opens a pull request when the profiles changed, so we can merge it before the release pull request.

• Trigger. release-please.yml calls it (workflow_call) when release-please creates or updates the release pull request. It can also be run by hand (workflow_dispatch, with a force input).
• Only when needed. prs_created is true every time the release pull request is updated, so after almost every merge. To not burn 20 minutes of emulator each time, the workflow first checks whether any library src/main changed since the last commit that touched the profiles, and skips everything else if not.
• Generation. Same API 36 google_apis image and pinned actions as the demo smoke test, with the key from ACTIONS_API_KEY. It fails right away if the secret is not there.
• Sanity check. .github/scripts/compare_baseline_profiles.py compares the regenerated profiles with the committed ones. It fails if a module keeps less than half of its rules or comes out empty, which is what happens with a placeholder key or demos that close themselves (it happened to me locally in maps-utils, and the generation still "succeeds"). It also ignores small differences: two runs never record exactly the same methods, so the pull request is only opened when more than 5% of the rules changed.
• Pull request. Opened (or updated, if one is already open) from the chore/regenerate-baseline-profiles branch with a chore: title so it does not bump the version, and a table with the rules before and after per module plus the classes added and removed. The profiles and test reports are also uploaded as an artifact.
• release-please.yml now sets permissions per job instead of at the workflow level, so the new job only gets contents: read (zizmor flagged the workflow-level contents: write and pull-requests: write).

Open questions

• Token. The pull request is opened with SYNCED_GITHUB_TOKEN_REPO, the token release-please already uses, because pull requests opened with GITHUB_TOKEN do not trigger the checks. @dkhawk, is it fine to use it here, or would you prefer another bot token?
• CLA. The commit is authored by github-actions[bot]. If cla/google does not accept it we can switch to the identity release-please commits with.

Testing

• actionlint passes on both workflows, and zizmor reports no medium or high findings (only the low self-repository hint for ./.github/...).
• The comparison script was tested locally with identical profiles, small noise (not significant), a big change (significant) and a near-empty regeneration (fails with an error per module).
• The staleness check was tested on a temporary worktree: up to date on this branch, stale after a change in maps-compose/src/main, up to date after a change only in maps-app.
• The workflow itself can only run once this is on main; I will trigger it by hand with force after merging.

[github-actions]

Coverage (unit tests)

Compared against 174f0fd on feat/baseline-profiles (#1060).

Module	Line %	Change	Branch %	Change
maps-compose	15.28%	no change	3.76%	no change
maps-compose-utils	6.09%	no change	4.47%	no change
maps-compose-widgets	10.88%	no change	11.11%	no change
TOTAL	12.99%	no change	4.12%	no change

_{Line and branch coverage from unit test reports. History is recorded on the coverage-history branch after each merge to feat/baseline-profiles.}

[googlemaps-bot]

Coverage (instrumentation tests)

Overall Project	43.69%	🍏

There is no coverage information present for the Files changed