Re: [BuildStream] Workspaces from CAS

[William Salmon <will salmon codethink co uk>]

On 24/07/2019 14:31, Darius Makovsky via buildstream-list wrote:
> There's been significant discussion about how to handle workspaces going
> forward [0]. One of the directions that has emerged is staging
> workspaces from the CAS. This would also be beneficial in the longer
> term for supporting remote builds. The basic sketch for workspace builds
> would change to:
>
> * import all sources from workspace into CAS (optimized with inode-based
> index file)
> * stage dependencies from CAS: if last-build is set then check dep cache
> keys
>    - if keys are changed then diff the staged dependency tree with the
> dependency tree from the previous workspace build. Set old timestamps
> for unmodified files. Apply diffs to modified files and stage those.
> * run integration commands
> * stage sources from CAS: if last-build is set then check source cache keys
>    - if keys are changed then mtime-aware diff current and cached. apply
> that diff on top of the old buildtree, and then stage that
> * run configure and build commands
> * regardless of whether the build is successful:
>    - store staged dependencies (whole sysroot) in CAS incl. timestamps
>    - store buildtree in CAS incl. timestamps (always, overriding
> buildtree user config)
>    - store new artifact cache key in workspace yaml file and set
> last-build field
>
> * ideas for tests:
>    - build workspace:
>      * check local CAS for all files before build
>      * check CAS buildtree for object files and that these are not
> present in the workspace
>
>
>   I think it makes sense to focus on supporting this for local builds
> first. There are still some open questions around performance and how
> best to handle file attributes in CAS: it's been suggested that the CAS
> directory proto might be extended to support that but that this would be
> an upstream divergence. The other obvious solution to that in the
> short-term would be to commit an inode-like index file to the local CAS
> which holds that information. I'd like input from the list on this
> please since it will comprise non-trivial changes.

Firstly the ablity to hold extra meta data than the cas currently 
provides is a blocker to this but affects a lot of other issues.

There was a lot of talk about trying to make this as compatible with 
other systems as possible. So other remote workers could eventually use 
it. I think this is very worth while, but again is not restricted to 
workspaces.

Like you point out, getting this to work locally should be a good first 
step but making sure that what ever you do with regard to meta data in 
cas based file systems is a big issue that i think would be unwise to 
proceed with if the suggested system can not be made to work with RE 
eventually or if it was so limited to only the time stamps and did not 
allow for other likely types of meta data to eventually be added.

I am happy with the general plan for workspaces but I think if you are 
going to add metadate to the cas then we need a much more detailed 
proposal before the list can give useful feedback.

> best regards,
> Darius
>
> [0] https://gitlab.com/BuildStream/buildstream/issues/985
>
>
>
> _______________________________________________
> buildstream-list mailing list
> buildstream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list