[thrtythreeforty]

This is a really interesting approach. How would you layer CI logic on top of this? Given your example workspace josh file,

    dependencies = :/modules:[
        ::tools/
        ::library1/
    ]

how are the canonical build artifacts for, say, ::library1/ determined, and how are they presented to the workspace?

I understand that the partial repo layering is the key innovation that exists a layer below what I'm talking about, but I'm trying to understand how you can ergonomically layer never-build-twice logic on top of it.

[chrschilling]

For the CI Josh is only used to determine if a given commit affects a given workspace. This can be done server side using the Josh GraphQL API. Having this understanding about the dependencies of workspaces understood by the vcs server(in this case Josh) means that such a query can be executed server side before any git clone/fetch needs to happen and in our case also before the CI allocates a machine to do the clone/checkout.

What artifacts are to be build inside a given workspace is totally up tho the build system(s) and tools that work after the files have been checked out to a working copy at which point Josh is not involved at all.