On Thu, 2014-06-12 at 18:06 +0300, Stoppa, Igor wrote: > On 12 June 2014 17:43, Patrick Ohly <[email protected]> wrote: > > > How would that work when building in OBS (see question above)? > > I'll describe what happens in production - plus some idea of how it > could be extended to devs. > > 1) Someone triggers a new build in OBS (so far this someone is a > release engineer, but it is possible to extend this also to devs) > > 2) the new build triggers the creation (in jenkins) of one or more > images, depending on the targets configured. > > 3) if said images can be built successfully, they are flashed and > tested (in a remote testing farm, which is part of the building > infrastructure). > Currently this happens with a fixed set of test cases, but it is > possible to make it conditional. For example to what comes from the > .spec file(s) of the package(s) that are new in the specific build.
Or that were recompiled because one of their dependencies changed. This would help detecting when a library update breaks other packages. This is very hard to test otherwise, both for the library maintainer and the maintainer of the component depending on a library. > > What you describe sounds like it is targeting developers who have a > > development work station and a separate device running some Tizen image. > > Currently we are targeting RE, so what we describe is necessarily > biased in that direction. It can be extended, though. I was thrown off track when Antii only talked about a developer using the test framework and by the reference to a connected Tizen IVI device. I wasn't aware that OBS is already hooked up to such real systems. Now it's a lot clearer, thanks. > But for individual developers, they already have means of creating > packages and images, so they could just use the flashing tool and then > manually start the execution of the selected test cases. That was also my thought, therefore I did not comment further on that aspect. > Why waiting in a queue on a remote farm during tight development cycles? > Better use local resources and do a remote submission when reasonably > sure if its quality. One reason for using a remote farm is that developers do not necessarily have access to real test devices. Using the same hardware for different developers is more cost-efficient, too, in particular when those developers are in different time zones and not active at the same time. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
