Hi folks, I agree that we need to sort out this story before 2.0. Tomaz, I have a clarifying question for your comment near the end of the message.
On Thu, Oct 1, 2020 at 10:45 AM Tristan Van Berkom <[email protected]> wrote: > > Hi, > > On Thu, 2020-10-01 at 10:38 +0100, Tomaz Canabrava wrote: > > 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. +1 > > 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. > > I believe that your use case is satisfied by: > > * Build it once > > * Build it repeatedly (however number of times you want to test > reproducibility of python.bst) using `--no-pull` after the > first build, while deleting only that artifact in between runs > locally. > > I.e. you won't need to download or rebuild all of those dependencies if > you have them already in your local cache from the last build. Tomaz, I think the question we need to ask is - do you expect to repeat the build locally or remotely. What Tristan describes would work IF both the initial build and the subsequent builds are happening locally. If you are expecting either of them to happen remotely, I don't think that can be solved just by BuildStream, as the RE endpoint would have its own caching mechanism. > Cheers, > -Tristan Cheers, Chandan On Thu, Oct 1, 2020 at 10:45 AM Tristan Van Berkom <[email protected]> wrote: > > Hi, > > On Thu, 2020-10-01 at 10:38 +0100, Tomaz Canabrava wrote: > > 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. > > I believe that your use case is satisfied by: > > * Build it once > > * Build it repeatedly (however number of times you want to test > reproducibility of python.bst) using `--no-pull` after the > first build, while deleting only that artifact in between runs > locally. > > I.e. you won't need to download or rebuild all of those dependencies if > you have them already in your local cache from the last build. > > Cheers, > -Tristan > >
