Route integration-tests trigger through emu-access runner#769
Merged
mihaimitrea-db merged 2 commits intomainfrom Apr 20, 2026
Merged
Route integration-tests trigger through emu-access runner#769mihaimitrea-db merged 2 commits intomainfrom
mihaimitrea-db merged 2 commits intomainfrom
Conversation
Co-authored-by: Isaac
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
hectorcast-db
approved these changes
Apr 20, 2026
…k-trigger-tests-emu-access
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
mihaimitrea-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
mihaimitrea-db
deleted the
mihaimitrea-db/unblock-trigger-tests-emu-access
branch
slimbnsalah
pushed a commit
to slimbnsalah/terraform-provider-databricks
that referenced
this pull request
Apr 21, 2026
…#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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Moves the
trigger-testsjob in.github/workflows/integration-tests.ymlfrom thedatabricks-deco-testing-runner-grouptodatabricks-release-runner-group-emu-access, so the cross-org GitHub App installation lookup againstdatabricks-engcan succeed.databricks-deco-testing-runner-groupdatabricks-release-runner-group-emu-accessubuntu-latest-decolinux-ubuntu-latest-emu-accessWhy
Between 2026-04-17 and 2026-04-20, the
databricksorg tightened its IP allow list. Since then, every PR-triggered Integration Tests run on this repo has failed:create-github-app-tokenresolves the installation for${{ secrets.ORG_NAME }}(databricks-eng) by calling/repos/databricks-eng/.../installation.gh workflow run sdk-java-isolated-pr.yml -R databricks-eng/...dispatch never happens.merge_groupauto-approves the check without running tests.The
emu-accessrunner 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 (supersedes #1616, verified green end-to-end on 2026-04-10).
The Go PR splits
trigger-testsinto two jobs:create-check— stays on deco, creates a same-org check run via thedatabricks/...check-runs API.trigger-tests— moves to emu-access, performs the cross-orgworkflow_dispatch.What this PR does differently
The Java SDK's
integration-tests.ymldoes not create a check run in the PR flow —trigger-testsonly 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, orcheck_run_idplumbing was needed here.Matches the equivalent Python SDK fix: databricks/databricks-sdk-py#1396.
How is this tested
This PR's own Integration Tests run is the test. Expected outcome:
trigger-testsruns on the emu-access runner andcreate-github-app-tokensucceeds (no 403).sdk-java-isolated-prworkflow_dispatchevent appears ondatabricks-eng/eng-dev-ecosystem.success/failurebased on the dispatched run.NO_CHANGELOG=trueThis pull request and its description were written by Isaac.