[Toaster] Design - dropping support for stand-alone analysis mode (7711)
Barros Pena, Belen
belen.barros.pena at intel.com
Wed May 20 01:54:13 PDT 2015
Hi David,
Thanks for going through the design documents and for the questions /
comments. I'll add an open to the Toaster call to discuss them (easier
than email, I think).
Cheers
Belén
On 20/05/2015 07:57, "Reyna, David" <david.reyna at windriver.com> wrote:
>Hi again,
>
>I am thinking about how on page 5 you expose the "Project ID" number.
>
>Are you sure you want to do that? That is an internal database integer
>that I think should be absolutely hidden. It could also be volatile and
>non-portable, if for example Alex should at some time in the future want
>to be able to renormalize/port/rebalance the database.
>
>I would think that the "Project Name" should the true and proper key for
>external lookup and access.
>
>If your concern is that the GUI user may randomly rename the project and
>thus break the external connection, then perhaps there could be some
>other unique and persistent ID that is created and associated with the
>project so that we can we keep its database internal index integer out of
>this, like how git has the commit ID instead of its database location.
>
>- David
>
>> -----Original Message-----
>> From: Reyna, David
>> Sent: Tuesday, May 19, 2015 3:26 PM
>> To: BARROS PENA, BELEN; toaster at yoctoproject.org
>> Subject: RE: [Toaster] Design - dropping support for stand-alone
>> analysis mode (7711)
>>
>> Hi Belén,
>>
>> I think that I am fine with this general design proposal.
>>
>> I have some comments and questions, mostly around the details for the
>> not-yet-written "How to set up an analysis project" content.
>>
>> 1) Connecting Analysis Projects to External Builds?
>>
>> It appears that the connection of analysis project to its build
>> directory and artifacts is solely managed by the external build system?
>> I assume that this is the case given the complexity and diversity of
>> possible external build systems?
>>
>> If that is the case, why do we support creating such project in the
>> Toaster GUI? Is it perhaps to support a use case where the Toaster user
>> would get the otherwise "unattached" project's ID number (on page 5)
>> and enter it in the external build system to complete that connection?
>>
>> 2) Use case for current local analysis workflow?
>>
>> Today you would use the tool "source toaster start" to connect a
>> specific build directory to a Toaster build, and the "external builder"
>> is in fact the command line user that initiates the build(s).
>>
>> Will we still support this general workflow? In other words, could be
>> provide the equivalent of ...
>>
>> $ cd <build_dir>
>> $ source toaster start [project_id]
>> $ bitbake core-image-base
>>
>> ... where some tool will be able to (a) attach this build to
>> <project_id> if that parameter is passed, (b) find the Toaster project
>> for this path if it exists and add this build, or (c) create a new
>> Toaster analysis project on the fly if this directory path is not
>> current used?
>>
>> I believe that this workflow is important because it provides
>> functional backwards compatibility, is easy to integrate for both
>> formal and informal "build managers", and provides an easy way for
>> reluctant command line users to get into the benefits of the deep
>> Toaster Analysis features.
>>
>> All of these reasons apply to Wind River and its use of Toaster.
>>
>> 3) Passing data from External Builder
>>
>> I assume that for external Build Managers the creation and population
>> of an Analysis Project's builds is along the same lines as you have
>> outlined in your Jenkins summary?
>>
>> In other words, contrary to your statement on page 3, Toaster does not
>> simply "collect" build information, it actually simply "receives" that
>> information and artifacts as passed by say the plug-in for Jenkins?
>>
>> Specifically, it would seem that (a) during the build the analysis data
>> would be passed directly from that remote bitbake instance to the
>> shared Toaster database, and then (b) upon success the selected build
>> artifacts would then be also be passed by the integration plug-in.
>>
>> - David
>>
>> > -----Original Message-----
>> > From: toaster-bounces at yoctoproject.org [mailto:toaster-
>> > bounces at yoctoproject.org] On Behalf Of Barros Pena, Belen
>> > Sent: Thursday, May 14, 2015 8:42 AM
>> > To: toaster at yoctoproject.org
>> > Subject: [Toaster] Design - dropping support for stand-alone analysis
>> > mode (7711)
>> >
>> > This Bugzilla feature
>> >
>> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7711
>> >
>> > Has considerable impact on how users interact with projects. If you
>> > can,
>> > please check the design document attached to the Bugzilla feature and
>> > comment as needed.
>> >
>> > Thanks!
>> >
>> > Belén
>> >
>> >
>> > --
>> > _______________________________________________
>> > toaster mailing list
>> > toaster at yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/toaster
More information about the toaster
mailing list