[YpNo]

BRIEF Change description

Fixes #12382

BigQueryDataset converts between BigQuery's FullID (projectID:datasetID) and a selfLink URL. Both directions are wrong when the project ID itself contains a colon.

Direction 1 : FullID -> resourceID / selfLink. Three call sites split FullID on every colon and require exactly two parts. A project ID can contain a colon:

Form	Example FullID	Colons
plain	my-project:my_dataset	1
domain-scoped (legacy)	example.com:my-project:my_dataset	2
universe-qualified	my-universe:my-project:my_dataset	2

For the latter two, create fails outright with The full ID of the created BigQueryDataset is expected to be in the format of projectID:datasetID, and the resourceID and selfLink mappings silently produce nothing.

Fixed by splitting on the last colon, via a shared parseDatasetFullID helper. Correct for every form, including the plain one.

Direction 2 : selfLink -> FullID. BigQueryDatasetStatus_ToProto stripped the URL prefix with strings.Trim, which takes a cutset rather than a prefix, so it removed characters from both ends:

in:  https://bigquery.googleapis.com/bigquery/v2/projects/my-project/datasets/my_dataset
out: jects/my-project/datasets/my_d

The following tokens[0] == "projects" guard therefore never matched, so FullID was silently never set — and had it matched, the dataset name was truncated. Changed to strings.TrimPrefix.

WHY do we need this change?

Direction 1 is a user-visible failure: creating a BigQueryDataset in a domain-scoped project (example.com:my-project) fails with an error saying the ID is malformed when it is valid. Domain-scoped project IDs have existed in public GCP for years.

Direction 2 is a silent correctness bug in the inverse mapping, affecting all projects.

I found these while working on universe support (#12374). Universe-qualified project IDs have the same shape as domain-scoped ones. But neither fix is universe-specific. Both are wrong in the public universe today, and neither needs any configuration.

Special notes for your reviewer:

The two fixes are in separate commits, so the second can be dropped if you would rather it went separately. I kept them together because they are the two directions of the same conversion, in the same file, and fixing only one would leave the pair inconsistent.

strings.Split(selfLink, "/") in direction 2 is left as-is and is correct. Project IDs cannot contain /, so a colon inside one survives the split intact.

No API, schema, or behavioural change for project IDs without a colon. parseDatasetFullID returns ok=false for malformed input, preserving the existing error path in the controller.

Does this PR add something which needs to be 'release noted'?

Fixed BigQueryDataset failing to reconcile in projects whose project ID contains a colon, such as domain-scoped projects (`example.com:my-project`). Creation previously failed with "The full ID of the created BigQueryDataset is expected to be in the format of projectID:datasetID", and the `resourceID` and `selfLink` fields were not populated.

• Reviewer reviewed release note.

Additional documentation e.g., references, usage docs, etc.:

Intended Milestone

No preference. Self-contained bug fix, no API change.

• Reviewer tagged PR with the actual milestone.

Tests you have done

New unit tests:

• pkg/controller/direct/bigquerydataset/utils_test.go : parseDatasetFullID across plain, domain-scoped and universe-qualified project IDs, plus rejection cases (no colon, empty, empty project, empty dataset, bare colon).
• pkg/controller/direct/bigquerydataset/bigquerydataset_mappings_test.go : resourceID and selfLink derived from FullID, and FullID derived back from a selfLink, each across all three project ID forms and a malformed input.

$ go test ./pkg/controller/direct/bigquerydataset/...
ok  	github.com/GoogleCloudPlatform/k8s-config-connector/pkg/controller/direct/bigquerydataset

25 passed, including the pre-existing fuzz roundtrip tests.

$ go vet ./pkg/controller/direct/bigquerydataset/...
$ gofmt -l pkg/controller/direct/bigquerydataset/     # clean

• Run make ready-pr to ensure this PR is ready for review.
• Perform necessary E2E testing for changed resources.

[anfernee]

Thanks for the patch!

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anfernee

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [anfernee]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[YpNo]

Hi,

Gently Up.

Regards.

[anfernee]

There are some test failures, can you take a look @YpNo ?

[YpNo]

There are some test failures, can you take a look @YpNo ?

Hi @anfernee,
I think it is a temporary failure and I cannot re-run the test :

Error: google-github-actions/setup-gcloud failed with: failed to retrieve versions from https://raw.githubusercontent.com/google-github-actions/setup-cloud-sdk/main/data/versions.json: read ECONNRESET

[anfernee]

Triggered the rerun!

[google-oss-prow]

New changes are detected. LGTM label has been removed.

[YpNo]

Hi @anfernee

The tests-e2e-fixtures-bigqueryconnection failure is artifact expiry. The job exits in 25s with Artifact not found for name: prebuilt-test-binaries. prepare-test-matrix uploads that with retention-days: 1, and this run was re-run ~26 days after it was created, so the artifact was long gone.

I have pushed an empty commit to trigger the whole build CI.