Build DocumentDB images from custom gitHub sources

[hossain-rayhan]

This is needed for personal testing.

[guanzhousongmicrosoft]

the PR is fine, but please set up the github repo so only admin/maintainers can start the build, so approve the build started by external contributors, to protect malicious PR and workflow build

[Copilot]

Pull request overview

Enables building DocumentDB extension and gateway images using configurable upstream sources for personal testing.

Changes:

• Adds workflow_dispatch inputs to override the DocumentDB release repo and gateway source image repo.
• Updates workflow-level env vars to derive DOCUMENTDB_RELEASE_REPO and GATEWAY_SOURCE_IMAGE_REPO from those inputs.

[hossain-rayhan]

the PR is fine, but please set up the github repo so only admin/maintainers can start the build, so approve the build started by external contributors, to protect malicious PR and workflow build

Allowed to modify only the repo/image name, not the owner. Now fork owner can only run workflow with their fork image and same for documentdb official repo.

[WentingWu666666]

Suggest taking full owner/repo paths as inputs instead of coupling to github.repository_owner

The current design always prepends ${{ github.repository_owner }} to user-supplied values, so the user can override the repo name but never the owner. That has a few problems:

1. The defaults are only correct on the upstream repo. On any fork say acme/documentdb-kubernetes-operator the default documentdb_repo: documentdb resolves to acme/documentdb, which probably doesn''t exist. The input has a "default" that''s effectively wrong everywhere except documentdb/documentdb-kubernetes-operator.

2. Common dev workflows break. A developer who forks only the operator and wants to build/test against the upstream documentdb/documentdb extension can''t they''re forced to also fork documentdb/documentdb into their org just to satisfy the owner coupling.

3. It conflates three independent things into one knob: the operator repo owner, the extension repo owner, and the gateway image registry path. They aren''t the same concept and shouldn''t be tied together.

4. The gateway_source_image framing is confusing. It''s described as "path under owner" but its default is documentdb/documentdb-local (itself a slash-separated path). When concatenated with owner you get a triple-segment ghcr path like ghcr.io/owner/documentdb/documentdb-local, which doesn''t match the "path under owner" mental model.

5. The security framing for restricting owner is weak. This is a workflow_dispatch workflow only people with write access to the repo can run it. Letting them point at an arbitrary org/repo isn''t meaningfully more dangerous than letting them edit the workflow file.

Suggested change take full paths

inputs:
  documentdb_release_repo:
    description: ''GitHub owner/repo for DocumentDB extension releases''
    required: false
    default: ''documentdb/documentdb''
  gateway_source_image_repo:
    description: ''Full container image repo for the gateway source image (registry/owner/path)''
    required: false
    default: ''ghcr.io/documentdb/documentdb/documentdb-local''

env:
  DOCUMENTDB_RELEASE_REPO: ${{ github.event.inputs.documentdb_release_repo || ''documentdb/documentdb'' }}
  GATEWAY_SOURCE_IMAGE_REPO: ${{ github.event.inputs.gateway_source_image_repo || ''ghcr.io/documentdb/documentdb/documentdb-local'' }}

Benefits:

• Defaults are correct on upstream and on any fork
• Forks of just the operator can still build against upstream extension releases
• The input names match what they actually contain (no hidden owner concatenation)
• One knob per independent concept; no implicit coupling to github.repository_owner
• The repository_dispatch trigger keeps working unchanged because the env defaults handle the case when no inputs are provided

[hossain-rayhan]

@guanzhousongmicrosoft / @WentingWu666666, Lets go back to original full path repo/image. Its cleaner. I will work with @xgerman to setup strict rules on who can run the workflow. I don't have admin permission.
Thanks.

[documentdb-triage-tool]

🤖 Auto-triaged by documentdb-triage-tool.

Applied: enhancement
Project fields suggested: Component ci · Priority P3 · Effort S · Status Needs Review
Confidence: 0.65 (mixed)

Reasoning

component from path globs (ci); effort from diff stats (14+6 LOC, 1 files); LLM: Adds CI workflow support for building DocumentDB images from custom GitHub sources, primarily for personal/developer testing convenience.

If a label is wrong, remove it manually and ping @patty-chow so the rules can be tuned. The bot will not re-label items that already have component labels.