Repository navigation
0.7.1: Run trusted Linux CI on Namespace #114
Description
Owner: Anders (@andersalm).
Decision: Namespace is not adopted. Keep CI on GitHub-hosted runners and let the trial end without a paid plan. PR #120 will close without merging after its release safeguards are extracted to #137.
Results
The trial produced faster Linux x86-64 checks and earlier failures. macOS still determined the full PR time. ARM64 stalled for about 89 minutes in one step, compared with a 36-minute GitHub job; further investigation was stopped. Comparison.
Review and disposition
Irzhy reviewed #120 at 8cc32664:
- F1: the workflow does not enforce the fork boundary. Repository access through both Namespace apps must be removed.
- F2: shared build caches can carry Namespace-built objects into release binaries. Build release tags without caches and restrict publication to tag pushes #137 makes tag builds cache-free.
- F3: manual dispatch defaulted to Namespace. The routing is being abandoned.
- F4: routing logic was duplicated. The routing is being abandoned.
Keep the useful publication guard in #137: release publication requires a version-tag push. The new PR also disables workflow caches for tag builds.
Remaining administration
Remove Elacity/elastos-runtime from Namespace Managed Runners and Namespace for GitHub. The current CLI token cannot list either installation's repositories; the settings page requires passkey confirmation. Exact settings and the final removal result will be recorded below. No paid plan is authorized.
Activity
[-]0.7.1: Compare Namespace builds and CI within the trial[/-][+]0.7.1: Run trusted Linux CI on Namespace[/+]andersalm commentedon Sep 29, 2026
PR #120 is open at
555aeca2and Irzhy has been asked to review it. The source checks and independent workflow review passed.The trial now has separate Ubuntu 24.04 x86-64 and ARM64 profiles, each with 8 CPUs and 16 GB RAM. Both use restricted Namespace API access and preserve the workflow's existing GitHub caches. The first source check started on a Namespace runner.
Comparison in progress:
ba43c06dec3712d72f57538ee9af3be8dac8e116. The runs report the branch head separately; checkout logs will verify the tested commit.The manual run also executes the full custody harness and uploads source-home artifacts. Those extra steps will be identified separately in the timing result; they are not a runner-speed comparison.
The repository requires approval for every external contributor's fork workflow. The workflow routes forks to GitHub. Namespace-side authorization for a fork that edits its own workflow is still unverified, so the PR remains draft. Profiles with restricted API access do not establish that separate rule.
andersalm commentedon Sep 29, 2026
PR #120 comparison on tested commit
ba43c06dec3712d72f57538ee9af3be8dac8e116. Both source-gate checkout logs show this exact commit.GitHub run: all eight checks passed. Namespace PR run: seven passed; ARM64 exceeded the 90-minute limit.
Namespace used 8 CPUs and 16 GB RAM per Linux job. GitHub used public Ubuntu 24.04 runners with 4 CPUs and 16 GB RAM (specifications). This compares the proposed configurations rather than equal hardware. Matched lint, Runtime, capsule and Linux source-home jobs reported cache misses on both services. The Namespace ARM64 runner was native aarch64; its timeout annotation confirms the limit was reached. The cause of its slower build remains open.
The manual GitHub run executed the full custody harness (23m14s); the PR run skipped the harness because its paths did not change. That job is excluded from the speed comparison. The manual run also uploaded release artifacts. Both Mac jobs used GitHub, so their 45m19s and 50m15s times are excluded too. Queue time is job creation to start; elapsed time is job start to completion.
Decision: use Namespace for x86-64 and keep ARM64 on GitHub. One trial supports this choice; it does not establish a general speed guarantee. The workflow retains its 90-minute limit and all existing tests.
Pushed fallback commit
8cc326645f36138b27e7871d8ebe61591bf82892to PR #120. It changes runner routing only. Local actionlint, YAML/routing checks, Home entropy, Rust formatting and diff checks passed. Independent source review found no issues. Final candidate CI passed all eight checks at8cc32664. This result is separate from the comparison above. The PR is ready for Irzhy's review. Anders contacts him; review requests remain clear.GitHub requires approval for all external contributor workflows. The checked-in workflow sends forks to GitHub. Reviewers must check runner routing before approving a changed fork workflow, because an approved modified workflow can request Namespace. Restricted Namespace profiles limit Namespace API access; they do not replace that review.
andersalm commentedon Sep 29, 2026
The new merge gate is still open. I checked Namespace’s organization and repository pages, runner profiles, workspace settings, and its access-control documentation. I found the GitHub App permissions and profile API access levels, but no verified control that refuses fork PR jobs. The Restricted profile controls Namespace API access from a running job; it does not establish fork admission policy. GitHub’s approval requirement for all external contributors is already enabled.
PR #120 remains open. Its passing CI and source review do not replace this check. The next proof must be a Namespace admission setting or provider confirmation, followed by a harmless fork job that changes the runner label and is refused. A job waiting for GitHub approval would not prove refusal by Namespace. The one-run macOS trial remains after this gate and the merge.
Preliminary monthly cost estimate, 29 September:
Current Namespace prices: $0.0015 per unit-minute for pay-as-you-go or overage; Team is $100/month with 100,000 units; Business is $250/month with 250,000 units. The account billing page agrees. Keep paid use subject to Anders’s decision. Update this estimate after the macOS trial and before the trial expires.
andersalm commentedon Sep 30, 2026
Repository removal is blocked by GitHub permissions: both installation API requests returned HTTP 403. The browser also requires owner sign-in confirmation.
An Elacity organization owner can open each setting, remove
Elacity/elastos-runtimeunder Repository access → Only select repositories, then save:Leave other repositories unchanged. If this is the only selected repository, GitHub may require removing that installation instead.
No app access or billing setting was changed. Namespace is not adopted; let the trial end without selecting a paid plan.
andersalm commentedon Sep 30, 2026
Decision complete: Namespace is not adopted; #120 is closed without merge.
#138 retains only tag-push publication and cache-free tag builds. @irzhywau is requested to review it; #137 owns the remaining checks and merge.
Irzhy’s four findings remain recorded above: fork trust, release-cache provenance, manual routing and repeated routing rules. The routing work is abandoned.
Both app-removal requests returned HTTP 403. An organization owner must use the two exact settings to remove this repository.
The trial should end without a paid plan. No billing change was made.
Closing as not planned, with the app-access action left explicit for the owner.