Repository navigation
Conversation
The README said in three places that fork pull requests are refused, but the workflow has deployed them from refs/pull/<N>/head with the trusted DockerBuild/ since 4f634fc. Every mention now matches the code, and the security note explains what guards a fork deploy instead.
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 preview README gives two opposite answers about fork PRs. Three places say we refuse them: line 75, line 104 and line 646. Line 612 says we deploy them. The code has deployed fork PRs since 4f634fc03 (2026-09-07). This PR makes the README match the code everywhere. Docs only, no code changes.
Why this matters
The worst stale line was in the security note: "Fork pull requests are refused outright." A member who believes it can comment
/deployon a fork PR without reading the diff, because they expect the workflow to block it. The workflow does not block it. The fork's code is built and started in a container that has the real databases andconfig_secrets.jsonmounted (deploy.sh L704-L705). ARAX in that container calls external KPs, so it also has outbound network. A wrong sentence in a security note is worse than no sentence.What protects the host when a fork PR is deployed
pull/<N>/headinstead of the branch name (L111-L116, L166-L167). GitHub keeps a copy of every PR head in our repo under that ref, so the image can get it fromRTXteam/RTX.DockerBuild/too, not the fork's (L234-L263). So a fork cannot change the Dockerfile, thedocker runflags or anything on the host outside the container.What a fork can still do: its code runs inside the build, for example
pip install -r requirements.txtfrom the fork's tree (CICD-Dockerfile L70), and inside the running preview, next to the secrets. Nothing in the code stops that. The only guard is the member who reads the diff before/deploy./redeployalso fetchesrefs/pull/<N>/head(deploy.sh L563-L566), so every new push to the fork needs a new read before the next/redeploy.What changed in the README
Links point to the new text.
pr-head/DockerBuildis the build context only for PRs from a branch onRTXteam/RTX. Fork PRs use our ownDockerBuild/.PREVIEW_BUILD_CONTEXTrow adds the fork case./redeploytoo, and after every new push./redeployworks on fork PRs.Not in this PR
The wiki ARAX Maintenance SOP has the same stale note at line 482 ("forks are not supported"). It needs the same fix. I did not edit the wiki.