Repository navigation
Deploy explicitly requested DGX fixes with verified code recovery - #616
Merged
Merged
Conversation
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
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.
The DGX worker can now fulfil an initial task that explicitly says to deploy a completed fix. After publication, the coding run requests the exact merged SHA; the controller rechecks the task and invokes an operator-bound deployment command. Tasks without a deployment request have no deployment effect. The command verifies the clean running revision locally and through the public endpoint, retains receipts for interrupted execution, and restores the previous code after failed startup. A cancelled task can reconcile an already-started deployment but cannot start another one.
The existing launcher now passes the selected port to deployment health verification, and the deployment helper refuses a stale expected-main revision before advancing the primary checkout. Automatic code deployment uses a prepared, separate runtime worktree and unchanged dependency lock; database migrations and environment upgrades require separate preparation.
The public DGX site uses Cloudflare Access. A configured, signed service identity can now read only GET /health without becoming a Von user. Human login and private routes retain their checks. Health requests never follow redirects with credentials. Real Cloudflare service issuance uses a scalar audience, which is accepted only for the configured health principal; wrong issuer, audience, identity and private-route requests remain denied.
Validation: 80 focused tests across the worker, deployment helper, canonical deployment and Cloudflare identity boundary pass, including a real failed process start followed by restoration of the previous Git revision and HTTP service. A further 37 launcher tests pass. Ruff, shell syntax and diff checks pass. A token issued through the actual Cloudflare Service Auth policy returned 200 on the candidate health route and 403 on its private route, with no user session. Full installed-worker/public-runtime acceptance follows merge and is tracked in JVNAUTOSCI-2740. The polling interval was separately changed to five minutes at Michael's request.