This adds a new Website/Docs for Snix, using Thulite / Doks, which is mostly hugo and a bit of npm. Change-Id: Iea10d4068fa783ec0ddd6bcaba5c8d92b1a1168f
		
			
				
	
	
		
			45 lines
		
	
	
	
		
			1.7 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			45 lines
		
	
	
	
		
			1.7 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| ---
 | |
| title: "Reference Scanning"
 | |
| summary: ""
 | |
| date: 2025-03-14T14:14:35+01:00
 | |
| lastmod: 2025-03-14T14:14:35+01:00
 | |
| draft: false
 | |
| weight: 45
 | |
| toc: true
 | |
| ---
 | |
| 
 | |
| At the end of a build, Nix does scan a store path for references to other store
 | |
| paths (*out of the set of all store paths present during the build*).
 | |
| It does do this by (only) looking for a list of nixbase32-encoded hashes in
 | |
| filenames (?), symlink targets and blob contents.
 | |
| 
 | |
| As outlined in the [Builder Protocol]({{< relref "protocol" >}}) page, we
 | |
| don't want to introduce Nix specifics to the builder protocol, but if we simply
 | |
| do refscanning on the coordinator side, that side would need to download the
 | |
| produced inputs and scan them locally.
 | |
| 
 | |
| This is undesireable, as the builder already has all produced
 | |
| outputs locally, and it'd make more sense for it do do it.
 | |
| 
 | |
| Instead, we want to describe reference scanning in a generic, non-Nix-specific
 | |
| fashion.
 | |
| 
 | |
| ## Proposal
 | |
| 
 | |
| One way to do this is to add an additional field `refscan_needles` to the
 | |
| `BuildRequest` message.
 | |
| If this is an non-empty list, all `outputs` are scanned for these.
 | |
| 
 | |
| The `Build` response message would then be extended with an `outputs_needles`
 | |
| field, containing the same number of elements as the existing `outputs` field,
 | |
| describing which `refscan_needles` are found for each output.
 | |
| 
 | |
| If there's needles found, they will be a list of indexes into the
 | |
| `refscan_needles` field specified in the `BuildRequest` field.
 | |
| 
 | |
| For Nix, `refscan_needles` would be populated with the nixbase32 hash parts of
 | |
| every input store path and output store path. The latter is necessary to scan
 | |
| for references between multi-output derivations.
 | |
| 
 | |
| This is sufficient to construct the referred store paths in each build output on
 | |
| the build client.
 |