Hosted deployment: opt-in LocalDockerHost: container per job
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 18/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- docker
- Domain
- infrastructure, security
Research direction
This is design work that depends on open issues #325 (spec renderer) and #329 (shared ContainerLauncher), so start by reading those and the existing Sandbox launch path. The issue names the Worker, the Dispatcher and the rendered container spec as the parts involved. Done means an opt-in LocalDockerHost with the socket never mounted into the Worker, a short ADR, and the tests T01 to T04 passing, with the risk documented and the option off by default.
Written by the indexing model from the issue text.
Description
Part of ##316. Later.
Problem
Operators with a rootless or remote Docker daemon may want a fresh container per job on their own host. This needs a decision that differs from the current rule (no docker socket, no volumes).
Design
An opt-in LocalDockerHost behind the same ContainerLauncher and the same rendered container spec as the Sandbox. The socket is never mounted into the Worker. The risk (socket access equals root on the host for whoever controls the Dispatcher) is documented clearly, and the option stays off by default.
Scope
LocalDockerHost, configuration, tests, docs and a short ADR.
Depends on
##325 (spec renderer), ##329 (ContainerLauncher shared with the Sandbox).
Test cases
| ID | kind | level | case | expected |
|---|---|---|---|---|
| T01 | security | unit | the Worker container | the socket is never mounted |
| T02 | regression | unit | rendered arguments | equal the spec used by the Sandbox |
| T03 | happy | integration | opt-in enabled against a local daemon | one container per job, removed afterwards |
| T04 | docs | review | docs | state the risk and that it is off by default |
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 1
- Avg merge
- 1h 18m
- Merged PRs (30d)
- 186
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ExpidetGames/code-reviewer
-
area: app type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
ExpidetGames/code-reviewer#308 ·
Maintainers usually reply within 1 day
-
type: docs
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ExpidetGames/code-reviewer#94 ·
Maintainers usually reply within 1 day
-
area: app post-mvp type: feature
Difficulty 5/5 Over a week Newbie friendliness 12/100
ExpidetGames/code-reviewer#339 ·
Maintainers usually reply within 1 day
-
area: runner post-mvp type: feature
Difficulty 5/5 Over a week Newbie friendliness 12/100
ExpidetGames/code-reviewer#337 ·
Maintainers usually reply within 1 day
-
area: runner post-mvp type: chore
Difficulty 4/5 3-5 days Newbie friendliness 20/100
ExpidetGames/code-reviewer#336 ·
Maintainers usually reply within 1 day
All issues in ExpidetGames/code-reviewer
Similar issues
-
area:ui effort:S enhancement priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
QuantumNous/new-api#7839 ·
Maintainers usually reply within 1 day
-
good first issue maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
dark-princezz/stellar-hooks#1010 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
interledger/rhyza#352 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day