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. And there could be some extra directive (like FULL_SMOKE_TEST / UNIT_TEST / FLASH_ONLY) 4) results are published back to the OBS project that triggered the building > 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. > In OBS, there is only a Tizen build chroot, but not a fully booted Tizen > image. That's why we have Jenkins and MIC to produce images. I think the natural, evolutionary path would be to support those devs who are also package maintainer. So that they would be better equipped to ensure the quality of what they accept. This could probably still be supported by the same infrastructure, maybe with some ad-hoc increase of build/test bandwith. 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. 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. Even in such scenario, developers would use exactly the same test framework and test cases. Of course, depending on what one is working on, a real device might be needed. Alternatively, one could use the emulator. But yes, it was simpler for us to target first the real HW and avoid the extra complexity dealing with possible quirks introduced by the emulator scenario. -- cheers, igor _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
