Migrate Envoy reusable workflow logic (_request and dependencies) to toolshed

[phlax]

Summary

Migrate all reusable workflow logic (the _*.yml set rooted at request.yml/_request.yml) from envoyproxy/envoy into envoyproxy/toolshed as cross-repo reusable workflows.

This is a tracker / bot ticket — scope is large and invasive but unblocks several things at once.

Why

• Resolves Scorecard Pinned-Dependencies alert (envoy code-scanning #2630). Once the workflows live in toolshed, references from envoy become genuine cross-repo uses: and can be SHA-pinned (slotting into the existing toolshed bump automation).
• Cross-branch consistency by construction. Today request.yml exists on every release branch and pins _request.yml@main. Moving the logic out makes each branch's choice of dispatcher version explicit (a SHA) instead of implicit ("whatever's on envoy@main right now").
• Smaller pull_request_target blast radius. Dispatch logic stops living in the same repo where untrusted PRs land — structurally impossible for an envoy PR to alter the dispatcher.
• Reuse. Mirror repos / downstream consumers can import the same workflows cleanly.
• Envoy keeps only its own workflows (envoy-*.yml, mobile-*.yml, codeql-*.yml, scorecard.yml, etc.). The shared CI primitives live with the rest of toolshed.

Scope — workflows to migrate

Entry point + all _*.yml reusable workflows it pulls in (directly or transitively):

Entry / dispatch

• request.yml (the per-branch caller — stays in envoy but becomes a thin wrapper calling toolshed)
• _request.yml
• _request_checks.yml
• _request_cache.yml
• _request_cache_bazel.yml
• _request_cache_docker.yml

Load / run / finish (the "_load shit" + harness)

• _load.yml
• _load_env.yml
• _run.yml
• _finish.yml

Full directory: .github/workflows/. Bot should re-walk this list at execution time — set may have drifted.

What stays in envoy

Repo-specific top-level workflows only — request.yml (thin wrapper), envoy-*.yml, mobile-*.yml, codeql-*.yml, scorecard.yml, command.yml, pr_notifier.yml, stale.yml, toolchain-test.yml, copilot-setup-steps.yml, etc. All _*.yml move out.

Check / precheck / publish / misc reusable

• _check_build.yml
• _check_coverage.yml
• _check_runtime.yml
• _check_san.yml
• _precheck_deps.yml
• _precheck_external.yml
• _precheck_format.yml
• _precheck_publish.yml
• _publish_build.yml
• _publish_release.yml
• _publish_release_container.yml
• _publish_verify.yml
• _cve_fetch.yml
• _cve_scan.yml
• _mobile_container_ci.yml
• _upload_gcs.yml

Migration plan (for the bot)

1. Inventory & dependency walk. Starting from request.yml, recursively resolve every uses: ./.github/workflows/_*.yml and every action invocation, producing the full transitive set + a graph.
2. Port to toolshed. Move the _*.yml files into envoyproxy/toolshed/.github/workflows/ (consider a naming scheme — e.g. envoy-ci-*.yml — to avoid collision with toolshed's existing workflows). Rewrite local uses: ./.github/workflows/_x.yml → uses: envoyproxy/toolshed/.github/workflows/envoy-ci-x.yml@<sha>.
3. Audit secrets/permissions. Each reusable workflow's secrets: and permissions: blocks must be preserved exactly; cross-repo reusable workflows require explicit secrets: passthrough at every layer. Verify nothing implicitly relied on same-repo ${{ secrets.* }} access.
4. Audit pull_request_target semantics. Confirm caller-context behavior (token, github.event, env) is unchanged when the called workflow lives in another repo.
5. Rewrite envoy callers. Update envoy's request.yml and any other top-level workflows to point at toolshed-hosted SHAs. Local ./ paths remain only for envoy-specific glue.
6. Document in toolshed. Add usage docs + a changelog entry; the workflows become a public contract.
7. Roll out across branches. main first, then each active release/v* branch (each gets its own pinned SHA — that's the whole point).
8. Delete migrated _*.yml from envoy once green on all branches.
9. Close envoy code-scanning js: Update packages #2630 as fixed.

Risks / things to watch

• Toolshed already has its own .github/workflows/ — need a naming convention to avoid collision and to make ownership obvious.
• _run.yml is large and parameter-heavy; wide blast radius if its interface drifts during the move. Port verbatim first, refactor later.
• pull_request_target + cross-repo reusable workflows: behavior is supported but worth a smoke test on a throwaway branch before flipping main.
• Some _*.yml already reference toolshed actions at pinned SHAs (e.g. envoyproxy/toolshed/actions/...@<sha>). Those references should be re-pinned to whatever toolshed SHA the migrated workflows land at, to keep a consistent toolshed version per branch.
• request.yml lives on every branch and calls _request.yml@main — the new wrapper should call envoyproxy/toolshed/.github/workflows/envoy-ci-request.yml@<sha> per branch, with the SHA bumped by the existing toolshed automation.

Status

• Bot-driven dependency walk + inventory confirmed
• Workflows ported to toolshed
• Envoy request.yml rewritten on main
• Envoy request.yml rewritten on active release/v* branches
• Old _*.yml removed from envoy
• envoy code-scanning js: Update packages #2630 closed

/cc @phlax — bot will pick this up.