Move all asteroid apps to recipes-asteroid-apps

[LecrisUT]

By apps I mean all GUI based packages that should not depend on any watch specific layer. Have to confirm that none of these have a daemon attached to it. This PR is intended to lessen the build triggers for the CI

Currently the relevant repository is at LecrisUT/meta-asteroid-apps

[MagneFire]

Thanks again fro you valuable work on this!

However, I feel like the separation between apps and 'core' AsteroidOS is counter productive to the changes we made to unify all watch layers into a single repository.

This separation makes maintenance less straightforward.
Why should CI dictate this change? Couldn't we use the same commit message based trigger like you proposed for the meta-smartwatch layer?

[LecrisUT]

Not with some hard-coding exceptions, which would have to change as things are added. The three triggers implemented are:

• Changes to the meta-asteroid/recipes-asteroid/$PackageName without a [NoBuild] tag will trigger the package to build. Changes to any files in meta-asteroid will trigger both package and device build. These 2 are clashing with each other now
• Changes to some tracked repositories with comments like $Device: will trigger a device build. This list is hard to extend, and also hard to design the Regex to catch multiple device/multiple packages and any combination of those.
• Changes to some tracked repositories with comments like [Rebuild:$Device]: will trigger a device rebuild from scratch. Again, regex is hard.

The first one is the most versatile and friendly to outside contributors. But it also triggers excessive rebuilds which do not affect any specific watch as it is built for armv7.

But I also think it is more meaningful to do this separation, as well as separate the bblayer to be on top of each other meta-asteroid -> meta-smarwatch -> meta-asteroid-apps. Because we can do something like this: Build first layer on qemux86 and save initial caches -> Build second one for each watch, reusing the common results and rebuilding only what is necessary for each one -> Build third layer (can be done at the same time with second) for qemux86 -> Build and deploy the final device images and app packages. This also makes cleaning the workspace much safer if we can just clean specific layers.

[MagneFire]

Not with some hard-coding exceptions, which would have to change as things are added. The three triggers implemented are:

• Changes to the meta-asteroid/recipes-asteroid/$PackageName without a [NoBuild] tag will trigger the package to build. Changes to any files in meta-asteroid will trigger both package and device build. These 2 are clashing with each other now
• Changes to some tracked repositories with comments like $Device: will trigger a device build. This list is hard to extend, and also hard to design the Regex to catch multiple device/multiple packages and any combination of those.
• Changes to some tracked repositories with comments like [Rebuild:$Device]: will trigger a device rebuild from scratch. Again, regex is hard.

The first one is the most versatile and friendly to outside contributors. But it also triggers excessive rebuilds which do not affect any specific watch as it is built for armv7.

But I also think it is more meaningful to do this separation, as well as separate the bblayer to be on top of each other meta-asteroid -> meta-smarwatch -> meta-asteroid-apps. Because we can do something like this: Build first layer on qemux86 and save initial caches -> Build second one for each watch, reusing the common results and rebuilding only what is necessary for each one -> Build third layer (can be done at the same time with second) for qemux86 -> Build and deploy the final device images and app packages. This also makes cleaning the workspace much safer if we can just clean specific layers.

The obvious one to chose here in my opinion is the first. One, reducing the know how required by outside contributors is a great addition. We shouldn't make contributions less straightforward to benefit CI (It's a tool that's supposed to help us after all).

I'm still not entirely sold on why you'd want this specific separation between the meta-asteroid and meta-asteroid-apps. Does this difference cause a reduction in build time from 3 hours to 6 minutes (as described in AsteroidOS/asteroid#190 (comment))?
But a slight improvement I can see here that reduces the easy of use for new contributors is to still keep everything in the same repository (meta-asteroid) but have two layers stored in that repository (meta-asteroid-core and meta-asteroid-apps). This is similar to what webOS does: https://github.com/webOS-ports/meta-webos-ports

@FlorentRevest What are your suggestions on this?

[LecrisUT]

But a slight improvement I can see here that reduces the easy of use for new contributors is to still keep everything in the same repository (meta-asteroid) but have two layers stored in that repository (meta-asteroid-core and meta-asteroid-apps).

Actually, I forgot to consider that. Yeah that works perfectly well, either as recipes or as meta with their own layer are equally fine as long as they are in different folders.

I've done more reading on what the layer priority does and I don't see that it would do anything for the apps, the smartwatch layer though should be higher in priority.

Found out that what I was trying to achieve is a packages only image/target without the do_rootfs step. To that end, can we package the apps in a package group so that we can add/remove them?

We can have asteroid-image for production image, asteroid-core-packages a dummy target to build all relevant packages on qemu and the watches, asteroid-image-devel full image including debug packages, verbose boot screen and no boot tutorial ><.

[FlorentRevest]

Actually, I forgot to consider that. Yeah that works perfectly well, either as recipes or as meta with their own layer are equally fine as long as they are in different folders.

It is preferable as a recipes-*/ directory yes.

I've done more reading on what the layer priority does and I don't see that it would do anything for the apps, the smartwatch layer though should be higher in priority.

Indeed.

Found out that what I was trying to achieve is a packages only image/target without the do_rootfs step. To that end, can we package the apps in a package group so that we can add/remove them?

We could.

We can have asteroid-image for production image, asteroid-core-packages a dummy target to build all relevant packages on qemu and the watches, asteroid-image-devel full image including debug packages, verbose boot screen and no boot tutorial ><.

Note that the boot tutorial can be skipped with a long-press of the next button.