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.
 |