Hey, Responses inline
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, October 14th, 2020 at 11:45 AM, Tristan Van Berkom <[email protected]> wrote: > Hi, > > On Fri, 2020-10-09 at 14:24 +0000, > > Benjamin Schubert wrote: > > > Hey everyone, > > > > TLDR: I would like a way of allowing network access during builds on a > > per-element basis, to ease transition into BuildStream. > > > > I realize this has a potential to be highly controversial, but I think that > > the benefits in terms of ease of adoption makes it worth it. > > In my opinion, this has the potential to cause more harm than good. > A good question is, if you are going to poke holes in the sandbox and > allow network access, what's the point of using BuildStream at all ? The point is about being able to incrementally improve the way your builds are made. It can be extremely hard, or too costly for a company to move everything to a 'correct' point before being able to move to BuildStream. This opens more an easy adoption of BuildStream, by allowing most of the benefits of it, and allowing to improve the 'bad' elements later, rather than having a way of solving every problem before moving to it. For me, this is a key point that BuildStream offered, compared to, for example, Bazel, which is more or less 'all or nothing'. Yes, having network access during your builds can be bad, and we should absolutely discourage that. However, I strongly believe that in order to help with adoption, users should be allowed to explicitely ask the permission to shoot themselves in the foot. > The cache key loses a lot of meaning and no longer provides the kind of > guarantees it should, that at least the source code being built is > unique for the cache key... This is a tangential problem. You can still have repeatable builds, with unique cache keys even with network access. It is harder, and requires some infrastructure, but it is doable, and many companies already have such mechanism in place. > If network access were "supported", this could lead us down a road > where we are requested to rebuild things when artifacts are too old > (for instance, I cannot build against this dependency, because the > random source code it downloaded from the internet only 3 months ago is > no longer valid for me to build against). Again, if you download from the internet that is a problem. If you have already a cache for such dependencies in your organization, that is not a concern. > Mostly I worry that if we give users any opportunity to allow internet > access in builds, we almost guarantee that they will not do the minimal > legwork required to ensure their build works without network access. I believe that this is to the users to decide. We can make it very clear in the docs that this is a bad idea, and users can decide to shoot themselves in the foot. > Fixing your element to work without internet access can sometimes be a > pesky and annoying task, and it is one which only pays off in the long > run, which is where BuildStream provides your project real value. If > people have an escape hatch to this, they will take it - and then when > they suffer the consequences (only months or years later), they will be > right to blame us for our false promises regarding repeatability. No, again, this is a documentation concern. We can document that by using this you understand your element is not repeatable etc. Fixing 'one element' is something that is doable indeed. Doing that at a company scale, on large projects become extremely hard. Being able to move to BuildStream before, allows to stop the bleeding for new elements and cleanup the rest on a longer term. It also provides a much better visibility to which elements are not (necessarily) repeatable, since you now have to state it explicitely. So while users would be doing something that is not recommended, it would still help them move towards better builds. > I think this proposal is essentially an easy way to arm users against > themselves, and I worry much more about the negative impacts this can > have than I worry about the initial workload it takes to adopt a tool > which forces you build your code repeatably and reliably. This is a question of being able to migrate to a better integration build system versus not being able to. If a huge amount of work is required before moving, what do we offer over Bazel? > > Cheers, > > -Tristan Thanks for your answer! Cheers, Ben
