After discussions, we concluded that the relevance of the build-analysis mode as a stand-alone tool is diminished, and all current use cases, including command-line building support, can be supported by using projects with "build/configuration" bits disabled. The advantage is that the code paths would be easier to maintain. - migrate project-less data to a "default" project - drop "not MANAGED" code paths from the code base This needs to be documented in the release notes on upgrading.
Created attachment 2508 [details] Design - Build and analysis projects
While working on this issue, another apparent problem cropped up - In the models, we make a difference between a Build and a BuildRequest - the build request is the user action that asks the system to perform a build. In "managed mode", we've been conflating the "Build" and "BuildRequest" objects to show only "Builds" to the user, on the assumption that all builds in the system come are triggered by Build Request. This assumption is not true for build data coming in for builds triggered through external means - e.g. builds executed from the command line, or coming from CI infrastructure. We need to show this distinction to the user, and stop conflating these objects in the interface. This issue is tied to bug 7725, as "failed" builds referred in that bug are actually BuildRequests that failed to start a build. As such, properly exposing BuildRequests as what they are will also solve 7725 by being able to manipulate BuildRequests and Builds as different oobjects.
(In reply to comment #2) > While working on this issue, another apparent problem cropped up - > > In the models, we make a difference between a Build and a BuildRequest - the > build request is the user action that asks the system to perform a build. > > In "managed mode", we've been conflating the "Build" and "BuildRequest" > objects to show only "Builds" to the user, on the assumption that all builds > in the system come are triggered by Build Request. We do that because for users there are only builds. Build requests are a system construct: something that relates to how the build system and Toaster are implemented and behave behind the scenes. But users do not know, neither they care, about the difference. The moment they click 'build', the thing that comes up IS a build as far as they are concerned. > > This assumption is not true for build data coming in for builds triggered > through external means - e.g. builds executed from the command line, or > coming from CI infrastructure. Is this because only 'builds' (and not build requests) triggered by a external means will appear on Toaster? Or is this so that the buildslist command can also show build requests? > > We need to show this distinction to the user, and stop conflating these > objects in the interface. > > This issue is tied to bug 7725, as "failed" builds referred in that bug are > actually BuildRequests that failed to start a build. As such, properly > exposing BuildRequests as what they are will also solve 7725 by being able > to manipulate BuildRequests and Builds as different oobjects. I might be missing something here, but can't the command show both? I guess there will be an inconsistency between that command output and the Toaster interface, but I think that's better than having to add the build request construct to the GUI. In any case, we should provide the ability to delete builds from the GUI itself, so I assume lots of people will delete the builds from the GUI once that's in place.
> We do that because for users there are only builds. Build requests are a system construct: something that relates to how the build system and Toaster are implemented and behave behind the scenes. But users do not know, neither they care, about the difference. The moment they click 'build', the thing that comes up IS a build as far as they are concerned. I will rephrase this - there are two stages in the life of the build - the command given by the user, and the results of that command. Now, the results of a command can appear in the tables without the user triggering an action - because somebody else triggered this command, e.g an external CI system like Jenkins. I think it's important to make this distinction in the interface; > Is this because only 'builds' (and not build requests) triggered by a external means will appear on Toaster? Or is this so that the buildslist command can also show build requests? It is because 'builds' executed by other means are appearing in Toaster. > I might be missing something here, but can't the command show both? Yes, it can. The problem is that the interface needs to show both, too. If I show only "build requests", I will miss builds executed by CI. If I show only "builds", I will miss failed/in progress build requests.
I believe that after some discussion we agreed to create a build for every build request, and display only builds in Toaster, so changing this back to 'new'.
This was merged into master as commits: 160563532f87bd901e1cc6972fe238be87a8b63c bitbake: toaster: refactor the builds pages 2c7ed96b567386d0f57ad8c088790a515d17b7af bitbake: toaster: remove BuildRequest references c362e61ee2cc97b393f7002c4592787d6573080c bitbake: toaster: remove MANAGED references and related fixes.
Verified on master: c1df471feacaf2590216aa476ce242908dac38cf