On Thu, May 14, 2020 at 09:58:15AM -0300, Beraldo Leal wrote: > Hi Cleber, > > Thanks for the big picture, very helpful. I'm confident that the Next > Runner will be a turning point for Avocado. > > My comments are inline: > > On Wed, May 13, 2020 at 07:43:41PM -0400, Cleber Rosa wrote: > > ... > > > > Currently ongoing development > > ----------------------------- > > > > There has been three major types of developments around the Job API: > > > > ... > > > > 2. Introducing and porting Avocado's code to new combined settings > > module. This should allow the same experience for users of the > > command line tool giving option as command line arguments, users > > of the Job API providing the configuration as a dictionary, or > > users of both command line and Job API settings options with > > configuration files. > > > > 3. Making sure that features that work while running jobs on the > > command line (via "avocado run"), also work the same way in custom > > jobs. Recently a number of issues with output not being created > > when running custom jobs were fixed, but there are certainly many > > more to be found. > > > > > > Relationship with N(ext) Runner > > ------------------------------- > > > > The N(ext) Runner will only be considered "feature complete" when it > > is completely integrated into an Avocado Job. This means that the job > > files discussed on the previous section item #1 should behave the same > > with the current runner, or the "nrunner" implementation. The items > > #2 and #3, should, as much as possible be finished *before* that, given > > that not doing so will cast a number of questions on who the culprit > > for a bug is. Any bug will lead to the question: is it a Job API bug > > or a N(ext) Runner bug? > > Just one update about item #2 (the new settings modules): > > * avocado/plugins/ is done: today we have 70 calls to the new > `register_option()` method and there is no more old calls to > `add_argument()` here. >
Nice, thanks for the extra info and update. > * avocado/optional_plugins/ is almost done: 16 calls to the new > `register_option()` method and since that a few plugins are going to > be deprecated I have to double-check the missing ones. But I think > that are just a few. I also have an open PR here: > > https://github.com/avocado-framework/avocado/pull/3783 > In light of the recent deprecation of the remote/vm/docker runner plugins, I've reviewed my previous comments on that PR and merged it. > * avocado/core/ is also almost done: we have only 14 calls to the old > method. I'm still working on this. > OK. > About item #3, after your comment on #3796 and merge of #3812, I'm > working on the "download test output command" and the PR is on the way. > OK. > > ... > > > > Relationship with N(ext) Runner > > ------------------------------- > > > > ... > > > > One of the goals of this RFC, is to look at the proposal for the > > N(ext) Runner pending development tasks, and discuss an architecture > > that facilitates the implementation of the Requirements Resolver. > > I understand this N(ext) Runner "feature complete" effort it is crucial > for a lot of tasks that we are doing. So maybe we could have a complete > list of pending tasks as GitHub issues. > > I know that we already have a few of them, but I'm not sure if all are > there. > > So, maybe some kind of 'flag/label' (nrun2run), a 'column' on GitHub > Kanban or even both so we could easily track all pending tasks about > this. > > I have also created an epic issue to accommodate all issues: > > https://github.com/avocado-framework/avocado/issues/3818 > > Let me know if you guys have any objections to this. > The only objection is that we already a issue for that: https://github.com/avocado-framework/avocado/issues/3700 Which is also an epic. The text is slightly different, but I guess it captures the same idea. About the labels or even a dedicated column, I think either one are good ideas. I think we'll have a clearer vision of the pending tasks choose the tools once we discuss the RFC that I'm working on. > > > Next > > ==== > > > > Following this, I'll be posting an architectural blue print proposal > > for the missing pieces of the N(ext) Runner. Feedback on the proposal > > is much appreciated, and it's worth reminding everyone that there's no > > unworthy suggestion or question. > > I'm looking forward to reading it. \o/ > > Thanks again. > > -- > Beraldo > Thank you for the update and feedback! - Cleber.
signature.asc
Description: PGP signature
