The current deployment flow for git-backed namespaces is user-push: the user submits node specs along with a commit hash claim. The server only verifies that the commit hash exists in the repo; it does not fetch the actual content at that commit and compare it against the submitted payload. This means a user with namespace write access can claim any valid commit hash while deploying entirely different content, bypassing git-enforced PR review.
Proposed solution
Add a POST /namespaces/{ns}/sync-from-git endpoint that implements a DJ-pull model: the server itself fetches node specs from GitHub at the given ref, then deploys them. The user payload is the ref only, which can be a commit SHA or a branch name:
POST /namespaces/myproject.main/sync-from-git
{ "ref": "abc123" }
The server will resolve additional info from the namespace config:
github_repo_path = "owner/repo"
git_path = "metrics/"
It uses that info to fetch the tree at owner/repo/metrics/ @ abc123 from Github and deploys the fetched specs to myproject.main. The key change here is that user-submitted content is never trusted.
Notes
GitHubService already exists and handles auth, so we can extend it with a method to fetch the file tree at a given ref and parse YAML specs. The existing deployment orchestrator can be reused for the actual deploy once specs are fetched.
This endpoint should return the same DeploymentResult shape as existing deploy endpoints for consistency, and deploying a valid merged commit to main should succeed. However, attempting to call the endpoint with a ref that doesn't exist in the repo or on namespaces without github_repo_path configured returns a 400.
The current deployment flow for git-backed namespaces is user-push: the user submits node specs along with a commit hash claim. The server only verifies that the commit hash exists in the repo; it does not fetch the actual content at that commit and compare it against the submitted payload. This means a user with namespace write access can claim any valid commit hash while deploying entirely different content, bypassing git-enforced PR review.
Proposed solution
Add a
POST /namespaces/{ns}/sync-from-gitendpoint that implements a DJ-pull model: the server itself fetches node specs from GitHub at the given ref, then deploys them. The user payload is the ref only, which can be a commit SHA or a branch name:The server will resolve additional info from the namespace config:
It uses that info to fetch the tree at
owner/repo/metrics/ @ abc123from Github and deploys the fetched specs tomyproject.main. The key change here is that user-submitted content is never trusted.Notes
GitHubServicealready exists and handles auth, so we can extend it with a method to fetch the file tree at a given ref and parse YAML specs. The existing deployment orchestrator can be reused for the actual deploy once specs are fetched.This endpoint should return the same
DeploymentResultshape as existing deploy endpoints for consistency, and deploying a valid merged commit to main should succeed. However, attempting to call the endpoint with a ref that doesn't exist in the repo or on namespaces withoutgithub_repo_pathconfigured returns a 400.