Every Run has an associated workspace. The workspace is unique for every Run. But port it its "layers" will be reused when you restart a run from failed tasks.
A workspace cannot just be a simple "shared" directory between tasks for many reasons:
- tasks can be executed in parallel on different executors (and also on different architectures)
- Restarting a run from the failed tasks won't be possible since the "shared" directory will contain dirty contents caused by a failed task.
Instead, a workspace is conceptually a "tree" of layers. When a task wants to save something to the workspace it'll use the
When a task want's to restore a workspace it'll use the
A workspace is restored extracting all the files saved by every parent task starting from the root parent tasks until the direct parent. Files saved from a task that is not an ancestor of the current task won't be restored.
A task may have multiple parent tasks in such case the order of the related workspace layer extraction is undetermined.
Currently if the same file has been saved multiple times in differents tasks the workspace restoration will fail (or it'll cause unpredictable behaviors and will break the rule of workspace and Run reproducibility). In future the logic could be improved to permit overwriting a file from a parent task.
If in a previous parent a path was saved as a directory and later it's saved as a file (or viceversa), workspace restoration will fail.
Multiple isolated tasks
In this example there're two parallel builds for different architectures and related tests. There're not dependencies between the two different architectures build/tests
Test x86_64 restore the workspace it'll only restore the files generated by
Build x86_64 (
Multiple dependant tasks
In this example there're two parallel builds for different binaries, the tests tasks (
Test 1 and
Test 2) depenends on both builds.
Test 1 and
Test 2 restore the workspace they'll restore the files generated by both
Build x86_64 and
Build arm64. Note that the build steps saved the files under different paths so
Test 1 and
Test 2 will restore two files (
If the build steps saved the binary under the same path (like in the previous example), workspace restoration will fail since the same file is going to be restored two times with unpredictable behavior.