On Thursday 06 June 2013 11:06:39 Barros Pena, Belen wrote: > On Thursday, 6 June 2013 10:27, Calin Dragomir wrote: > > On 05.06.2013 20:14, Paul Eggleton wrote: > > > * I understand task_history is meant to capture where BitBake could have > > > accelerated the task using sstate but was unable to for some reason. Can > > > we have a choice field which indicates this directly (e.g. sstate_result > > > - not applicable, unavailable, failed, restored)? > > > I will change this task_history field into a CharField with only those 4 > > possible choices and will name it sstate_result. Belen, are you ok with > > this? Can you please update the info in the task table based on this? > > BELEN: Mmm, the question is that the history field will not only show > sstate-related outcomes. It is meant to tell "the story of the task", i.e > reveal the process BitBake followed to determine how to handle the task. > So, for example, for an "existing" task, it will tell me that BitBake found > a stamp file in location xyz, and that's why the task was not executed.
Right, so we can infer that based upon the value of the task_type field. > For an "executed" task, it might tell me that the checksum indicates task > inputs have changed and therefore the task needs to be executed, and it > will also show me the output of the bitbake-diffsigs command so that I can > check what changed in those inputs. For a "skipped" task, it will show me > which task brings in the skipped task, and so on. So I don't think the 4 > choices identified by Paul cover all the cases. I think that it does. The value of my proposed field should be filled in for both sstate and executed tasks, so we can know what happened during the sstate phase. I don't want to track this separately in a free-format text field because it's effectively another specialised event log that won't be easy to search/filter on and I don't think that's what we need. > > > * I agree we want to have a sequence number to allow us to easily show > > > the order tasks ran in within the UI where needed (is that task_number > > > in the current model? If so do we need the order field which is also > > > listed?) > > > > This is actually a question I had earlier. Task_number isn't listed in the > > table from bug #4275. We should drop on one of the task_number and order > > fields. I think order should be renamed as task_number in the table, and I > > will drop order in the Django model. Belen, do you agree ? > > BELEN: Happy with that. The label used in the UI for task_number should > still be 'order' though. Since the model definition is not set in stone perhaps we would be better advised to use the same terminology in the model definition as the UI; i.e. if "order" is preferred in the UI then let's use that in the model as well. > * What is the "code" field? > > On the agency page here ( > http://www.yoctoproject.org/webhob/phase3_final_web_prototype/project-build > -tasks-task.html) under the Code section I see a block of code, and this is > why I have put a TextField there. > > On the other hand, going through the tasks tabel v4 , I see that depending > on the script type, we have a path for shell and a path , function and line > number for python code. Belen, what is desired here exactly? > > BELEN: For shell tasks, the path to the shell script. For Python tasks, the > path to the shell script, the function(s) called and the start line for > each of those functions. The idea of showing code was specific to failed > executed tasks. For those, the idea was showing the code lines that threw > the error. Can we identify those? If the answer is yes, I need to add a new > information item to the list: "error code" or something like that. "error code" won't really work, since that would normally imply an error result code (number). In any case think we need to collect this information regardless of whether the task failed or not, so that the user can inspect it. Let's keep it simple and always collect the file and starting line number for both python and shell tasks (i.e. we need extra fields for this); for shell tasks we can also collect the run.do_xyz file and place its contents in this "code" field. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ webhob mailing list [email protected] https://lists.yoctoproject.org/listinfo/webhob
