On Thu, Oct 1, 2020 at 10:21 AM Jürg Billeter <[email protected]> wrote:
> Hi Tristan, > > On Thu, 2020-09-24 at 15:34 +0900, Tristan Van Berkom wrote: > > I am suggesting today that we need to consider the ability of > > disabling remote caches[0]: > > - Do we want it only for the toplevel project ? > > - Recursively ? with a -J/--cross-junctions option ? > > - With granular selection of which junctions to disable cache > > interactions for ? (with junction path specifications on the > > command line ?) > > I currently tend towards two knobs for this: > > * `--no-pull`, `--no-fetch` and the equivalent options in > buildstream.conf as described in #819. This would completely disable > pulling artifacts and fetching sources, resp. I.e., always across > junctions and also disable servers configured in buildstream.conf. > for the usecase I need, it would need to be element-dependant. for instance, I want to test the reprocibility of `python.bst`, so I need to block it from using the cache and do a build. but python depends on other things that I do want to use from the cache. --no-pull="element1.bst, element2.bst" would do the trick. * Add a config option to buildstream.conf to disable the use of > project.conf servers (can be set globally or per project). So if you > want to use your own server instead of the project.conf servers, you > can disable the project.conf server right next to the place where > you configure your own server. > > I think this covers the main use cases with minimal complexity. Or do > you have a use case in mind that needs per-junction configuration for > (temporarily) disabling network operations? > > The above would be in addition to the subproject config changes from > your earlier proposal. > > Side-note: As part of my Remote Asset API + blob-less Remote Execution > work, I'm planning to tweak artifact/source server configuration a bit > and add support for remote caching independent of artifact/source > servers. However, I expect these changes to be orthogonal to what we're > discussing here, so we shouldn't need to add this to the discussion > right now. > > Cheers, > Jürg > >
