When a build is pointed at a directory, what is packaged and sent to the builder before the first instruction runs?
answer
- packaging happens before step one
- scope is a path, not a list
- recursive, not the files you named
- one filter subtracts from the walk
- instructions read only from the bundle
basics
~20 sEverything under the directory the build was pointed at, recursively, minus whatever the ignore rules exclude. That packaged set is the build context, and it is transferred before step one. An instruction can only read files that are inside it.
solid answer
~50 sA build takes two separate inputs: the build description, which is the ordered list of instructions, and the **build context**, which is a path. Before any instruction is interpreted, the tool walks that path recursively, drops everything matched by the ignore rules, packages what is left and hands it to whatever is doing the building. The set is defined by the path, not by the files your instructions happen to name — nothing reads ahead to work out which files a copy instruction will want. Two consequences follow. A file above the path you pointed at is simply not in the set, so an instruction trying to copy it fails rather than reaching out to the filesystem. And every stray directory inside that path — build output, dependency trees, fixtures, version-control metadata — is packaged whether any instruction touches it or not.
code
pseudocode · 14 linescontext_root = the path the build was pointed at
rules = ignore rules read from that root
bundle = empty
for each file under context_root, recursively:
if file matches any rule in rules:
skip # never packaged, never transferred
else:
add file to bundle
send bundle to the builder
for each instruction in the build description:
run instruction # may read only from bundlego deeper
Remember the order: the directory you point at is walked and packaged first, and only then do the instructions run. That is why a copy of a file from outside that directory fails.
Be able to explain that the set comes from a path plus a filter, never from reading the instructions ahead of time, and name both levers that change it — the root you point at and the ignore rules.
Tie the scope to the two real symptoms: minutes of packaging before ten seconds of work, and a broad copy that could only sweep in what was sent. Say how you would confirm what actually crossed instead of guessing from the rules file.
The point worth owning is that the context root is an interface: where teams point their builds decides both their build latency and their exposure surface, and a monorepo whose builds all point at the root has made that decision once for everybody.
## The set is computed before anything runs A build has two inputs that people routinely merge into one in their heads. The first is the **build description**: the ordered instructions that say which base to start from, what to copy in, what to run and what the finished image should do. The second is the **build context**: a *path* you point the build at. The order of operations is the whole subject of this question. Before the first instruction is interpreted, the tool: 1. walks the path you gave it, **recursively**; 2. drops every path matched by the **ignore rules**; 3. packages what survives into one bundle; 4. transfers that bundle to whatever is performing the build; 5. *then* runs step one. So the file set is decided by a path and a filter, never by reading ahead through the instructions. Nothing inspects your copy instructions to work out a minimal set — a build whose instructions copy exactly one file still sends the whole directory that file lives in. ## Why the builder is not simply reading your disk It is tempting to picture the builder opening files out of your working directory as it goes. It generally does not, and the model is easier once you stop picturing that. The thing performing the build may be a separate process, a separate machine, or a shared build service somewhere else entirely; the packaged context is what crosses that gap. Treating the build as *"here is a self-contained bundle of files, now follow these instructions against it"* explains every behaviour you will actually hit: - **A path outside the context cannot be copied.** An instruction naming `../shared/config` fails, because that file was never packaged. The fix is to point the build at a higher directory (and pay for everything under it) or to bring the file inside. - **Untracked and uncommitted files are included.** The walk is a filesystem walk. Whatever your version-control system thinks about a file is irrelevant; if it is on disk under that path and no ignore rule matches it, it is sent. - **Your local editor droppings, caches and prior outputs are included too**, for the same reason. - **The set is recomputed on every build.** How many of its bytes actually cross the wire each time depends on the builder — some transfer the whole bundle, some synchronise only what changed — but the *scope* is re-decided every run from the same path and the same rules. ## The two levers on the set | lever | what it changes | when to reach for it | |---|---|---| | the path you point the build at | the root of the walk, so everything outside it is unreachable | a repository holding several independently built components; point each build at its own subdirectory | | the ignore rules | subtracts matching paths from the walk's result | the normal case: one tree, most of it irrelevant to the build | | moving data out of the tree entirely | removes the file from any possible context | large fixtures and sample data that no build should ever see | The ignore rules are the reviewable lever: they live in a file next to the code, they are read in review, and they apply to every invocation that uses that context root. Narrowing the path is blunter and lives in the invocation rather than in a checked-in file, so it is easy for one caller to get right and another to get wrong. ## Why an interviewer asks this at all Because two very different problems have the same root, and both are common. The first is **transfer cost**: a build whose real work takes seconds can spend minutes packaging and shipping a working tree full of dependency directories and old output. The second is **exposure**: a copy instruction that takes the whole context can only take files that were sent in the first place, so the size of the set is also the size of what a careless instruction can sweep into an image. A candidate who says *"only the files my instructions copy are sent"* has both problems ahead of them and no model for diagnosing either. ## The boundary of the idea This is strictly the *packaging and transfer* step. What the builder then does with those files instruction by instruction — what it reuses from the previous run, what ends up in which layer, and what a credential does once it is written into one — is a different subject with its own mechanics. Here the only question is: which files crossed, and who decided that?
- Does the build description itself have to live inside the directory you pointed the build at?Usually not — most tools accept the description's location as a separate input, so it can sit outside the context path. That changes nothing about the set: the packaged files are still everything under the context path minus the ignore rules, and instructions can still read only from that set.
- Is pointing the build at a subdirectory the same thing as adding ignore rules?It has the same effect on the packaged set — everything outside the new root is unreachable — but it is blunter and it lives in the invocation rather than in a checked-in file. Ignore rules are reviewable and apply to every caller using that root; a narrowed path only applies to the caller that remembered to narrow it.
- If a file is sent but no instruction ever copies it, is it in the finished image?No. Being in the context only makes a file available to instructions. It still crossed to the builder, though, which matters when the builder is shared or remote and keeps what it received — so "not in the image" is not the same as "never left your machine".
You asked a print shop to print one page, and posted them the whole filing cabinet because the page was in it. You pay postage on the cabinet, and everything else in it is now sitting on their desk.
saying these in an interview costs you the question
- Only the files a copy instruction names are sent to the builder.
- The builder reads files straight from the working directory as it goes.
- Files the version-control system ignores are automatically left out.
- Ignore rules only shrink the finished image; the files are still sent.
- Pointing the build at the repository root costs nothing extra.
- An instruction can reach a file just above the directory you pointed at.