## Summary

Moves the `trigger-tests` job in
`.github/workflows/integration-tests.yml` from the
`databricks-deco-testing-runner-group` to
`databricks-release-runner-group-emu-access`, so the cross-org GitHub
App installation lookup against `databricks-eng` can succeed.

| | Before | After |
|---|---|---|
| Runner group | `databricks-deco-testing-runner-group` |
`databricks-release-runner-group-emu-access` |
| Label | `ubuntu-latest-deco` | `linux-ubuntu-latest-emu-access` |

## Why

Between **2026-04-17** and **2026-04-20**, the `databricks` org
tightened its IP allow list. Since then, every PR-triggered Integration
Tests run on this repo has failed:

- `create-github-app-token` resolves the installation for `${{
secrets.ORG_NAME }}` (`databricks-eng`) by calling
`/repos/databricks-eng/.../installation`.
- The deco runner group's egress IPs are no longer on the allow list, so
that call returns **403**.
- The downstream `gh workflow run sdk-java-isolated-pr.yml -R
databricks-eng/...` dispatch never happens.
- Merges still go through only because `merge_group` auto-approves the
check without running tests.

The `emu-access` runner pool's egress IPs **are** on the allow list, so
the installation lookup succeeds from there.

## Where the changes come from

Ported from the Go SDK fix:
[databricks/databricks-sdk-go#1638](databricks/databricks-sdk-go#1638)
(supersedes #1616, verified green end-to-end on 2026-04-10).

The Go PR splits `trigger-tests` into two jobs:

- **`create-check`** — stays on deco, creates a same-org check run via
the `databricks/...` check-runs API.
- **`trigger-tests`** — moves to emu-access, performs the cross-org
`workflow_dispatch`.

## What this PR does differently

The Java SDK's `integration-tests.yml` **does not create a check run**
in the PR flow — `trigger-tests` only performs the cross-org dispatch.
Nothing needs to stay on the deco runner, so the equivalent minimal fix
is a single runner-group change on the existing job rather than a
two-job split. No job splitting, added dependencies, or `check_run_id`
plumbing was needed here.

Matches the equivalent Python SDK fix:
[databricks/databricks-sdk-py#1396](databricks/databricks-sdk-py#1396).

## How is this tested

This PR's own Integration Tests run is the test. Expected outcome:

- [ ] `trigger-tests` runs on the emu-access runner and
`create-github-app-token` succeeds (no 403).
- [ ] A `sdk-java-isolated-pr` `workflow_dispatch` event appears on
`databricks-eng/eng-dev-ecosystem`.
- [ ] The Integration Tests check on this PR transitions to `success` /
`failure` based on the dispatched run.

---

`NO_CHANGELOG=true`

This pull request and its description were written by Isaac.

…#5609)

## Why

Between **2026-04-17** and **2026-04-20**, the `databricks-eng` org
tightened its IP allow list. Since then, every `pull_request`-triggered
Integration Tests run on this repo has failed silently:

- The `trigger-tests` job in `.github/workflows/integration-tests.yml`
runs on `databricks-deco-testing-runner-group` (label
`ubuntu-latest-deco`).
- That job calls `actions/create-github-app-token` with `owner: \${{
secrets.ORG_NAME }}` (= `databricks-eng`), which resolves the
installation via `/repos/databricks-eng/.../installation`.
- The deco runner pool's egress IPs are no longer on the
`databricks-eng` allow list, so that lookup returns **403**.
- The downstream `gh workflow run terraform-isolated-pr.yml -R
databricks-eng/eng-dev-ecosystem` never dispatches.
- Merges still land only because the `merge_group` `auto-approve` job
rubber-stamps the check without running tests.

The `databricks-release-runner-group-emu-access` pool's egress IPs
**are** on the `databricks-eng` allow list, so moving the cross-org
dispatch job to that pool unblocks the lookup.

## What changed

Minimal 2-line runner swap on the `trigger-tests` job only:

| Before | After |
|--------|-------|
| `group: databricks-deco-testing-runner-group` | `group:
databricks-release-runner-group-emu-access` |
| `labels: ubuntu-latest-deco` | `labels:
linux-ubuntu-latest-emu-access` |

### Not changed
- `check-token` job — runs a shell script checking secret presence; no
external calls, stays on deco.
- `auto-approve` job — creates a same-org check via `context.repo`,
unaffected by the cross-org allow list, stays on deco.
- Any other workflow (`tagging.yml` uses the same app-token action but
for same-org release work; unaffected).
- Private-side `eng-dev-ecosystem` workflows — no changes required; the
private workflow already accepts `pull_request_number` + `commit_sha`.

## Why a single runner swap (vs. Go SDK's job split)

The Go SDK fix (databricks/databricks-sdk-go#1638) split `trigger-tests`
into a `create-check` job (stays on deco, creates a same-org check run)
+ a `trigger-tests` job (moves to emu-access, does the cross-org
dispatch). That was needed **only** because the Go SDK workflow creates
a `check_run` on the public repo and passes `check_run_id` into the
private workflow.

This repo's workflow does **not** create a check run — `trigger-tests`
calls `gh workflow run terraform-isolated-pr.yml` and nothing else. No
`check_run_id` is produced or passed. Same shape as Python SDK and Java
SDK, so the minimal single-runner swap is the right fix. No job
splitting, no new dependencies, no `check_run_id` plumbing.

## Reference PRs (same pattern, already merged)

- Python SDK: databricks/databricks-sdk-py#1396
- Java SDK: databricks/databricks-sdk-java#769
- Go SDK (different shape — split into two jobs — for contrast, not to
mirror): databricks/databricks-sdk-go#1638

## Test plan

The PR's own Integration Tests run is the test. Expected outcome:

- [ ] \`trigger-tests\` runs on \`linux-ubuntu-latest-emu-access\` and
\`create-github-app-token\` succeeds (no 403).
- [ ] A \`terraform-isolated-pr\` \`workflow_dispatch\` event appears on
\`databricks-eng/eng-dev-ecosystem\`.
- [ ] The \`Integration Tests\` check on this PR transitions to
\`success\` / \`failure\` based on the dispatched run.
- [ ] Existing \`merge_group\` \`auto-approve\` path still works
unchanged (not touched by this PR).

NO_CHANGELOG=true

## Why

Between **2026-04-17** and **2026-04-20**, the `databricks-eng` org
tightened its IP allow list. Since then, every `pull_request`-triggered
Integration Tests run on this repo has failed silently:

- The `trigger-tests` job in `.github/workflows/integration-tests.yml`
runs on `databricks-deco-testing-runner-group` (label
`ubuntu-latest-deco`).
- That job calls `actions/create-github-app-token` with `owner: \${{
secrets.ORG_NAME }}` (= `databricks-eng`), which resolves the
installation via `/repos/databricks-eng/.../installation`.
- The deco runner pool's egress IPs are no longer on the
`databricks-eng` allow list, so that lookup returns **403**.
- The downstream `gh workflow run terraform-isolated-pr.yml -R
databricks-eng/eng-dev-ecosystem` never dispatches.
- Merges still land only because the `merge_group` `auto-approve` job
rubber-stamps the check without running tests.

The `databricks-release-runner-group-emu-access` pool's egress IPs
**are** on the `databricks-eng` allow list, so moving the cross-org
dispatch job to that pool unblocks the lookup.

## What changed

Minimal 2-line runner swap on the `trigger-tests` job only:

| Before | After |
|--------|-------|
| `group: databricks-deco-testing-runner-group` | `group:
databricks-release-runner-group-emu-access` |
| `labels: ubuntu-latest-deco` | `labels:
linux-ubuntu-latest-emu-access` |

### Not changed
- `check-token` job — runs a shell script checking secret presence; no
external calls, stays on deco.
- `auto-approve` job — creates a same-org check via `context.repo`,
unaffected by the cross-org allow list, stays on deco.
- Any other workflow (`tagging.yml` uses the same app-token action but
for same-org release work; unaffected).
- Private-side `eng-dev-ecosystem` workflows — no changes required; the
private workflow already accepts `pull_request_number` + `commit_sha`.

## Why a single runner swap (vs. Go SDK's job split)

The Go SDK fix (databricks/databricks-sdk-go#1638) split `trigger-tests`
into a `create-check` job (stays on deco, creates a same-org check run)
+ a `trigger-tests` job (moves to emu-access, does the cross-org
dispatch). That was needed **only** because the Go SDK workflow creates
a `check_run` on the public repo and passes `check_run_id` into the
private workflow.

This repo's workflow does **not** create a check run — `trigger-tests`
calls `gh workflow run terraform-isolated-pr.yml` and nothing else. No
`check_run_id` is produced or passed. Same shape as Python SDK and Java
SDK, so the minimal single-runner swap is the right fix. No job
splitting, no new dependencies, no `check_run_id` plumbing.

## Reference PRs (same pattern, already merged)

- Python SDK: databricks/databricks-sdk-py#1396
- Java SDK: databricks/databricks-sdk-java#769
- Go SDK (different shape — split into two jobs — for contrast, not to
mirror): databricks/databricks-sdk-go#1638

## Test plan

The PR's own Integration Tests run is the test. Expected outcome:

- [ ] \`trigger-tests\` runs on \`linux-ubuntu-latest-emu-access\` and
\`create-github-app-token\` succeeds (no 403).
- [ ] A \`terraform-isolated-pr\` \`workflow_dispatch\` event appears on
\`databricks-eng/eng-dev-ecosystem\`.
- [ ] The \`Integration Tests\` check on this PR transitions to
\`success\` / \`failure\` based on the dispatched run.
- [ ] Existing \`merge_group\` \`auto-approve\` path still works
unchanged (not touched by this PR).

NO_CHANGELOG=true