[Internal] Increase tests coverage for manual resources#5776
Open
tanmay-db wants to merge 4 commits into
Open
Conversation
PR #5759 switched the SDKv2 "raw HTTP" resources to inject the X-Databricks-Workspace-Id routing header per-callsite. This adds apply-based acceptance tests that exercise that path end-to-end via a provider_config { workspace_id } block (create + read round-trip), verifying each resource lands in the right workspace through the SDK workspace client. Coverage added (TestMwsAccUnifiedHost* = account provider on the unified host; *_WorkspaceLevel = normal workspace provider, added only where no real apply test existed before): token, dbfs_file, cluster, instance_pool, sql_query, sql_visualization, sql_table, table (legacy), provider (sharing), instance_profile (AWS-gated), permission_assignment The existing *_provider_config_test.go tests are PlanOnly and never hit the API, so they do not cover this. Resources intentionally not covered (with rationale in the file header): sql_dashboard/sql_widget (legacy create disabled server-side), mount + variants (already covered, no SDK GET), sql_permissions (needs table-ACL cluster), obo_token (cross-level admin SP setup), sql_global_config (shared singleton needing the cross-test lock). Test-only change; no production code touched. The two workspace-level tests were verified green against a live AWS workspace; the unified-host variants run in the integration-test workflow where UNIFIED_HOST is provisioned.
tanmay-db
requested review from
hectorcast-db
and removed request for
a team and
hectorcast-db
Adds a normal-workspace-provider apply test (*_WorkspaceLevel) alongside the existing unified-host test for every resource in the suite, so each resource is exercised both ways: account provider on the unified host (routing header) and a plain workspace-level provider on a normal host. Both reuse the same helper, so the only difference is the provider factory + env. New workspace-level tests: token, cluster, instance_profile, sql_query, sql_visualization, sql_table, provider (sharing). (dbfs_file, instance_pool and table already had one.) databricks_permission_assignment stays unified-only: it assigns an account-level principal, which a workspace-level provider cannot create in a self-contained test.
Three tests added on this branch failed the integration runs: - databricks_table (TestUcAccTable_WorkspaceLevel + TestMwsAccUnifiedHostCreateTable): the column block omitted the required type_json field, so CreateTable failed with "Missing required field: column_0.type_json". Add type_json, matching the working config in catalog/grant_test.go. - databricks_permission_assignment (TestMwsAccUnifiedHostCreatePermissionAssignment): the databricks_service_principal dependency is a dual account/workspace resource, which must declare `api` on a unified host (common/unified_provider.go). Plan failed with "please set api to account or workspace". Set api = "account". - databricks_instance_profile (TestAccInstanceProfile_WorkspaceLevel): the test used TEST_EC2_INSTANCE_PROFILE, a real profile already attached to the workspace, so create failed with "already been added to WorkerEnvId". Register a unique throwaway ARN with skip_validation = true instead: self-contained, no shared-fixture conflict with the parallel TestAccInstanceProfileIntegrationSuite, and it also un-skips the account-level variant (no TEST_EC2_INSTANCE_PROFILE dependency). Verified locally: InstanceProfile passes against a live AWS workspace; the table type_json error no longer occurs (apply proceeds past table validation). Co-authored-by: Isaac
TestMwsAccUnifiedHostCreatePermissionAssignment failed on gcp-acct-prod-is with "Permission assignment APIs are not available for this workspace." databricks_permission_assignment requires the target workspace to be enabled for identity federation (i.e. assigned a Unity Catalog metastore); the GCP plain-account test workspace is not federated. The AWS/Azure account workspaces and all UC-account workspaces are, so the test keeps running there. Skip only on GCP + plain ACCOUNT env, leaving coverage intact everywhere else. Co-authored-by: Isaac
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. |
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
1 participant
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.
WIP
Changes
Tests
NO_CHANGELOG=true