GNOME Bugzilla – Bug 781450
Don't automatically build
Last modified: 2018-01-11 10:26:59 UTC
Since 3.24, Builder has developed a mind of its own - when I open some projects, it independently starts to build them, often downloading dependencies in the process. This behaviour is disturbing - Builder feels out of control, and I don't understand what it is doing or why.
Some discussion from IRC: feaneron (IRC) - it annoys me when Builder decides on behalf of me that I want to compile the application Allan Day - i'm not against doing things automatically. it feels wrong in this case though feaneron (IRC) - it is a slow, long operation that can consume bandwidth sometimes i'm on a limited connection, and Builder tries to download half of gnome to build Calendar on Flatpak i literally had financial loss because of that Allan Day - feaneron: the answer to that might be that builder should be aware when you're on a metered connection downloading things automatically isn't always wrong my issue is that it's unclear what's going on, and it's surprising feaneron (IRC) - downloading is part of the building process Allan Day - but why is it building? i just opened a project - i didn't ask it to build it for me feaneron (IRC) - apparently, builder needs to build the project to have realistic code comprehension. i.e. make cache Allan Day - what is "code comprehension" used for? feaneron (IRC) - to colorize function names, macros and types differently and to provide code completion afaik Allan Day - feaneron: so if your project fails to build, you don't get those things? feaneron (IRC) - i think they don't feaneron (IRC) - i'm not sure though Allan Day - i also wonder how frequently the project needs to be rebuilt to keep those features working feaneron (IRC) - every character you type, appearently. or every time you save a file mclasen (IRC) - I believe the idea is to make building something that you don't need to ask for it just happens needs some fine-tuning, probably but generally seems sound to me Allan Day - mclasen: if that's the case i wonder if automatic builds should be so prominent. you could make it much more of a background task the problem is that you open the project and things start dancing across the screen and complaining when they fail
Sorry for the network costs Georges :( Indeed we cannot provide meaningful information in the editor unless the build system has reached a point where we can extract metadata, access headers, python modules, etc. The layers that query for this information request that the build pipeline reach a certain point before moving forward. Of course, every keypress, had the previous request failed (which happens when canceling), it will try to get CFLAGS/etc again to provide up to date information. There are a couple ways we can try to address this which come to mind. 1. Bring free fiber internet to the world including buses, planes, and trains. 2. Track that the build was manually cancelled and automatically cancel future build requests until the "build" or "rebuild" GActions have been activated. (Automated API does not use the GAction, and therefore will not muck up our user state tracking). 3. Provide an "offline mode" that will refuse to perform IDE_BUILD_PHASE_DOWNLOADS in the build pipeline. If we allow the "query" phase to occur, but not the execution of the download build stage, we should be able to continue working without network, even if the downloads phase has to execute but needs to do nothing. Problems 1. Physics 2. Still requires user feedback to cancel a build/active network transfers. 3. This doesn't solve the problem where your build system fails and every key press just keeps trying to rebuild and fail. So equally frustrating, but for an arguably smaller chunk of the pie. At the moment, I'm inclined to suggest #2 and backport to 3.24.
In my mind there are two separate issues here: the bandwidth issue and the general surprise/unpredictability issue. The bandwidth issue doesn't seem all that different to automatic downloads of software updates. In that context we try to avoid incurring charges by avoiding downloads on metered connections. For surprise and unpredictability, we could consider a number of options: * Don't have a prominent visual indication that there is a build ongoing. I think this is important if the build is happening automatically and in the background. * When running an automatic build, we ought to describe it in a way that communicates what its purpose is. * Avoid triggering automatic builds at certain times. For example: when you've just opened a project, or for projects that have never been successfully built with the current build profile. * If the project hasn't been successfully built recently, we should consider showing some feedback that code analytics are unavailable, along with an explanation of why and how to enable them. * Add an automatic builds setting, since some users might choose to run builds from the command line, or might want more manual control.
(In reply to Christian Hergert from comment #2) ... > Indeed we cannot provide meaningful information in the editor unless the > build system has reached a point where we can extract metadata, access > headers, python modules, etc. > > The layers that query for this information request that the build pipeline > reach a certain point before moving forward. ... So these could be partial rather than full builds?
(In reply to Allan Day from comment #4) > So these could be partial rather than full builds? Yes. Generally it would be something like: - Any downloads that are necessary - ./autogen.sh if necessary - Run ./configure - Perform a "dry run" of make, without building anything to look for variables used by GCC/Clang.
(In reply to Allan Day from comment #3) > The bandwidth issue doesn't seem all that different to automatic downloads > of software updates. In that context we try to avoid incurring charges by > avoiding downloads on metered connections. We don't have a great way to do this today without adding a preference for "download while on metered". But we should probably default to "no" either way. > For surprise and unpredictability, we could consider a number of options: > > * Don't have a prominent visual indication that there is a build ongoing. I > think this is important if the build is happening automatically and in the > background. Yes, definitely worth designing for this. > * When running an automatic build, we ought to describe it in a way that > communicates what its purpose is. We'll have to change some API in Builder to provide a "build reason". We might get away with something like a "classification" of the build. So an enum like: IDE_BUILD_REASON_USER_REQUESTED IDE_BUILD_REASON_CODE_INDEXING IDE_BUILD_REASON_DIAGNOSTICS ... > * Avoid triggering automatic builds at certain times. For example: when > you've just opened a project, or for projects that have never been > successfully built with the current build profile. We don't build when opening a project until we restore the files. It's the buffer loading that causes the code highlighter to start, which in turn forces a build. If there are no open files, we shouldn't build upon load. > * If the project hasn't been successfully built recently, we should > consider showing some feedback that code analytics are unavailable, along > with an explanation of why and how to enable them. Excellent idea. > * Add an automatic builds setting, since some users might choose to run > builds from the command line, or might want more manual control. We don't do "automatic builds" in the sense of full builds. Our "automatic builds" are to provide the features in the editor (ie: they don't actually build anything beyond the dependencies).
Created attachment 350355 [details] [review] transfer: fail transfer stages when on metered connections If we are on a metered connection, then we don't want to be downloading things like SDKs and such. Default to setting disable-when-metered to TRUE. Note that if the ::query() phase of the build stage marks the transfer as completed, then the stage will not fail. A followup commit will contain the ability to configure if you want to download on metered connections.
Created attachment 350356 [details] [review] gsettings: make downloads over metered connections configurable Some people may always be on metered connections, or specifically want to download updates while transiently on a metered connection. This allows the user to override the setting and do that. In some ways, I wish we would provide UI flow when the problem exists, but this is a stop-gap until we think about how we'd even go about doing that. I suspect it's more effort than it's worth.
Attachment 350355 [details] pushed as db9568f - transfer: fail transfer stages when on metered connections Attachment 350356 [details] pushed as 197e48a - gsettings: make downloads over metered connections configurable
(In reply to Christian Hergert from comment #6) > (In reply to Allan Day from comment #3) > > The bandwidth issue doesn't seem all that different to automatic downloads > > of software updates. In that context we try to avoid incurring charges by > > avoiding downloads on metered connections. > > We don't have a great way to do this today without adding a preference for > "download while on metered". But we should probably default to "no" either > way. Won't builds simply fail if they require a download and downloads are disabled? > > For surprise and unpredictability, we could consider a number of options: > > > > * Don't have a prominent visual indication that there is a build ongoing. I > > think this is important if the build is happening automatically and in the > > background. ... My attempt to resolve this presents these automatic builds differently from where user-initiated builds are shown: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/builder/builder-build-and-operations-popovers.png This communicates that the automatic builds are different. Presenting them separately from user-initiated builds also avoids the feeling that something that is usually under user control has been taken from them. > > * If the project hasn't been successfully built recently, we should > > consider showing some feedback that code analytics are unavailable, along > > with an explanation of why and how to enable them. > > Excellent idea. There's an attempt to do that in the mockups linked to above.
(In reply to Allan Day from comment #10) > (In reply to Christian Hergert from comment #6) > Won't builds simply fail if they require a download and downloads are > disabled? Yes, but the UI sort of spastic while that happens on high-frequency. > My attempt to resolve this presents these automatic builds differently from > where user-initiated builds are shown: > > https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/ > builder/builder-build-and-operations-popovers.png > > This communicates that the automatic builds are different. Presenting them > separately from user-initiated builds also avoids the feeling that something > that is usually under user control has been taken from them. I think we can do this pretty well combined with the IDE_BUILD_REASON_* stuff above. > There's an attempt to do that in the mockups linked to above. Looks good, I like it!
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-builder/issues/221.