Phase 1: use GitHub App token in tools test workflows

[ihalatci]

Phase 1 of the GH_TOKEN -> GitHub App migration

Migrates the five tools test workflows from the org PAT secrets.GH_TOKEN to a per-job
GitHub App installation token:

• tool-tests.yml
• packaging-methods-tests.yml
• statistic-tests.yml
• statistic-schedule.yml
• citus-package-all-platforms-test.yml

What changed

Each consuming job now mints a token with actions/create-github-app-token@v2 (using the existing
org secrets GH_APP_ID / GH_APP_KEY, owner: citusdata) and exports it to \
as GH_TOKEN (plus GITHUB_TOKEN for the all-platforms test). The GH_TOKEN entries are
removed from the top-level env: blocks, because top-level/job env cannot reference the
steps context.

Why this is safe / zero-downtime

• An installation token is a drop-in replacement for the PAT (token-type-agnostic): no tools
  package or script changes, no re-tag.
• secrets.GH_TOKEN is intentionally left defined org-wide so other (not-yet-migrated) workflows
  and build branches keep working during the staged migration.
• Lowest-risk first slice: these are PR/schedule-triggered test workflows with no release publishing.

Validation

First CI run on this PR also validates that GH_APP_ID / GH_APP_KEY are visible to the
tools repo and that token minting works.

[ihalatci]

Phase 1 status — token migration validated ✅

This PR migrates the tools test workflows from the org PAT GH_TOKEN to a GitHub App
installation token minted in-workflow (actions/create-github-app-token@v2).

Validated

The App-token flow is green in CI:

• Generate GitHub App token → success
• Export GitHub App token to environment → success
• GH_TOKEN populated for downstream steps.

Important config finding

GH_APP_ID is an org variable, not a secret (App IDs are non-sensitive). The first run failed at
the mint step with [@octokit/auth-app] appId option is required because secrets.GH_APP_ID
resolved empty. Fixed by referencing it as:

app-id: ${{ vars.GH_APP_ID || secrets.GH_APP_ID }}

(GH_APP_KEY remains a secret.) This var-or-secret pattern will be reused in later phases.

Known unrelated CI failure (NOT from this change)

The remaining red check is a pre-existing failure, independent of this migration:

• Test: packaging_automation/tests/test_update_docker.py::test_pkgvar_postgres_version_existence
• Error: KeyError: 'postgres_15_version'
• Cause: setup_module() does git clone https://github.com/citusdata/docker.git (no token, public)
  and the test asserts postgres_14_version / postgres_15_version. The docker repo's current
  pkgvars now contains only postgres_16/17/18 (PG14/15 removed upstream), so this assertion fails
  on any run today — including develop — regardless of the token change.

Recommend fixing that stale assertion separately to keep this PR token-only.

[ihalatci]

Follow-up: full accounting of the red checks (all token-independent)

Across the 3 edited workflows that ran on this branch, every App-token step is green and the
token is populated downstream (GH_TOKEN: ***, and in Python github_token = '***'). The remaining
failures are pre-existing / environmental, not caused by the token swap:

1. Stale pkgvars assertion — test_pkgvar_postgres_version_existence
   (KeyError: 'postgres_15_version'). Clones citusdata/docker (no token) and asserts PG14/15, but
   docker's pkgvars now has only PG16/17/18.

2. Missing packaging-test images — test_build_package_debian / test_build_package_rpm
   (ValueError: Unable to find image 'citus/packaging-test:debian-stretch-all' locally, also
   almalinux-9-pg17). The token is present and valid; the package-build tests fail because those
   Docker images can't be pulled (e.g. Debian stretch is EOL). Pulling Docker Hub images doesn't use
   GH_TOKEN, so this is unrelated to the migration.

These same failures occur on develop under current conditions (the last green develop runs predate
the upstream pkgvars/image drift). They should be addressed separately to keep this PR token-only.