Hi all,
As I have been thinking through the current architecture proposals for
Toaster-1.7 and the workflows, I have come up with the following questions.
1) Remote build artifacts
Alex has introduced the valuable concept of remote builds, which has many
implications. for example the de-emphasis of the idea of a "local.conf" editor,
given that in the remote build scenario that file only exists for the duration
of the build as per the independent remote agent.
I do think that we need to add to the configuration of a "Project" the ability
to list which build artifacts the developer would like returned from that
remote build (together with where to store those files locally). This is
because that remote project and those artifacts could non-deterministically
disappear, just as the project creation itself is non-deterministic in time.
Proposal: I would think that a simple checklist would suffice, for example,
On Failure:
[ ] Error Logs
On Success:
[ ] Kernel Image
[ ] File System Image(s) (either all, or provide a list of potentially
verions)
[ ] SDK
[ ] Custom from Path:[./path/to/file] (for custom targets)
If the build is local, then presumably this list would be by default disabled.
2) Toaster versus Command line
One of the painful lessons Wind River learned was to not have the GUI tools
lock out the command line user, that a developer can move between these tools
as their needs require. My specific case in point was with a project creation
tool (a predecessor to Workbench) that kept private state on a given project's
configuration. While this was logical from the GUI developer's point of view,
this had the devastating consequence that one a project was managed by the GUI
it could only be managed going forward by the GUI, and command line users (80%
of developers) would then immediate give up the GUI even where it would have
provided substantial benefit.
Proposal: Here is my simple proposal towards this. In the "project import"
feature, also allow an import from an existing local build's configuration
files (e.g. "local.conf", "bblayers.conf", and "default-image.bb" for the
excluded packages). This would support a developer doing iterative development,
and allow them to switch between command line and Toaster as appropriate and
boost adoption. I would also like "automatic-imports" so that the local
workflow is seamless between Toaster and command-line usage.
3) Local Builds
Belen has mentioned that given Toaster is primarily a remote interface, the
remote build support would be given priority over local builds as far as
features would go. I hope though that we do still given local builds adequate
support. I do not have any blockers that I am aware of yet, but I want to keep
this on the table.
(a) I plan to remove Wind River's project configuration tool in favor of
Toaster, but if it cannot support local builds then Toaster loses a lot of
value for us. I do not mind doing extra work to meet my requirements on top of
Toaster, I just do not want changes that block what we can do in this regard.
(b) For development and testing, the local case is probably what we will
always start with since it is the fastest iterative environment. Subsequent
builds may then be farmed out to the remotes, either because at that point the
builds are more stable or that the user has run out of time and wants the build
to run until they come back later.
(c) For initial users and build managers, they will probably also start with
the local case before they get to the remote case.
4) Distinguishing Project builds
Paul describes the term "Project" as "simply a configuration set". That is
fine, but we need a term to distinguish between the instantiated versions of a
"project", especially in the Toaster interface. Here is my most simple use case
that I am thinking through.
(a) I have my project "A" farmed out, it gets build, and the results
returned.
(b) I have my project "A" farmed out again, where the configuration is the
same but perhaps the "poky" pull may be different.
First Question: As per this example's premise, does a "project" also explicitly
capture the poky branch(es) in addition to the configuration? How else would a
remote builder know what to build the project against.
Second Question: How to I distinguish the results of the first pass with the
second? They would both rightly have the same "project" name as a parent so
that is not sufficient, plus I cannot depend on time causality because they
could end up being executed at any time. I could show the column for the host
name where it was executed, but that could be non-deterministic. I could in
this case show the column for the commit ID, but that would most likely be hard
to translate plus this may not be the distinguishing characteristic.
Idea: perhaps we could allow a user to define a "Job Name" for a given project
build, so that they can personally correlate the results to the request. I
think that the term "job" correctly connotes the remote and asynchronous nature
of what is happening together with the expectations of how it works.
Thanks,
David
--
_______________________________________________
toaster mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/toaster
