Changes to the all builds page (YB6682)

Changes to the all builds page (YB6682)

[Barros Pena, Belen]

Changes include adding a table listing all projects. Design document
attached to the Bugzilla feature, as usual:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6682

Belén

Re: Changes to the all builds page (YB6682)

[Reyna, David]

Hi Belén,

Thank you for making the proposed changes easy to follow!

Here are my questions.

1) Is this page also used for the normal non-project builds? If so, what is used in the project name space for those?

2) In the "All Projects" page, you have the column "Release". How is this actually used? Perhaps I need to go back the definition of a "release". 

For me I would be doing multiple builds of the same project to test for regressions against a "release", where each build is against a different label point. But in that case I do not see a column for the git checksum at the top of the respective build's pull. Isn't a release every 6 months? So this column's data would only have mixed content if the database captures data over a really long period of time?

What if you are doing identical builds but with different hosts? But I do not see a column for the host information.

Perhaps my  information is over in the "project details " page.

- David

> -----Original Message-----
> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
> Sent: Monday, September 22, 2014 6:54 AM
> To: toaster@yoctoproject.org
> Subject: [Toaster] Changes to the all builds page (YB6682)
> 
> Changes include adding a table listing all projects. Design document
> attached to the Bugzilla feature, as usual:
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6682
> 
> Belén
> 
> --
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster

Re: Changes to the all builds page (YB6682)

[Barros Pena, Belen]

Hi David,

Thanks for reviewing the design. Long answers (I'm afraid) inline. I hope
they make sense.

Cheers

Belén

On 24/09/2014 10:07, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi Belén,
>
>Thank you for making the proposed changes easy to follow!
>
>Here are my questions.
>
>1) Is this page also used for the normal non-project builds? If so, what
>is used in the project name space for those?

No, not really. This comes back to the 2-modes Toaster has. If you are
using Toaster in analysis only mode (1.6), you should see the old 'all
builds' page, populated with any builds built outside of a project. If you
are using Toaster in 'projects' mode (1.7), you see the new 'all builds'
page, populated with any builds built inside a project. Both modes should
be kept separate, even if for some reason you are switching between
Toaster modes and storing to the same database in the process (we don't
really envision people doing this though).

>
>2) In the "All Projects" page, you have the column "Release". How is this
>actually used? Perhaps I need to go back the definition of a "release".

The release determines the version of BitBake you are using to build
within a certain project, and the default version of the metadata. Right
now, it's looking like we'll ship Toaster configured to support 2
releases: 1.7 and master. Projects and releases have a 1:1 relationship.
You can change the release you are using for a certain project, but a
project can only be associated with one release at any point in time. The
Release column just shows you the project release as it is set when you
retrieve the information.

>
>For me I would be doing multiple builds of the same project to test for
>regressions against a "release", where each build is against a different
>label point. 

To do something like this you will have to set up a release for each
'label point' you want to build against in the toasterconf.json file. Then
you can either create separate projects, or change the selected release
within a given project. Keep in mind that the release mainly determines
the version of BitBake you want to use, and by extension the default
version of the metadata. However, you can change the version of the
metadata you are building using the import layer functionality. You can
import a layer and set it to any branch, and you can build the tip of that
layer's branch with the version of BitBake specified by the project
release. 

So I might have a project with release Yocto Project 1.7 'Dizzy', which
means that it will build using BitBake as released with 1.7. That project
will have 3 layers by default: meta, meta-yocto and meta-yocto-bsp, all 3
set to the 'dizzy' branch, because the selected release also determines
the default version of the metadata. Within that project I can import my
layer meta-belen specifying the branch 'master', and I will build the tip
of the meta-belen master branch using the version of BitBake released with
Yocto Project 1.7.

Alex, Paul: if I am explaining this wrong, please correct me.

>But in that case I do not see a column for the git checksum at the top of
>the respective build's pull.

I hope the above answers this question. The version of BitBake is
determined by the release. Then you will have a git checksum for each
layer. 

> Isn't a release every 6 months? So this column's data would only have
>mixed content if the database captures data over a really long period of
>time?

Yes, or if you have projects using different versions of BitBake. You
might want to experiment with master in a 'playing around' project, but
have your customer's projects always against 1.7.

Keep in mind that releases are customisable via the toasterconf.json file.
If you are a Linux vendor shipping Toaster to your customers, you might do
so with releases myproduct_v1 and my product_v2, instead of Yocto Project
releases. When you set up the releases in the toasterconf.json file, you
will need to specify the default version of the metadata to be used with
each release. So the hard work needs to be done by the person setting up
Toaster. Once everything is set up, users are never exposed to this
complexity: for each project, they see layers that are compatible with the
release they are using, and can override that for their own, imported
layers.

>
>What if you are doing identical builds but with different hosts? But I do
>not see a column for the host information.

I am assuming that when you say 'host' you mean the machine actually
running the build. Well, Toaster does not know about the hardware running
the builds: that's for your continuous integration software to handle.
Toaster is hardware agnostic: it doesn't care if you build is run on an
Ubuntu 12.04 machine or in a Fedora 19 machine or in the same machine that
hosts Toaster or in a different one. The 'host' is where we draw the line
between Toaster and continuous integration software.

>
>Perhaps my  information is over in the "project details " page.
>
>- David
>
>> -----Original Message-----
>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
>> bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
>> Sent: Monday, September 22, 2014 6:54 AM
>> To: toaster@yoctoproject.org
>> Subject: [Toaster] Changes to the all builds page (YB6682)
>>
>> Changes include adding a table listing all projects. Design document
>> attached to the Bugzilla feature, as usual:
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6682
>>
>> Belén
>>
>> --
>> _______________________________________________
>> toaster mailing list
>> toaster@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster