Re: [DISCUSSIONS] CI build

[Claudius Heine <claudius.heine.ext@siemens.com>]

Hi Maxim,

On 22/05/2019 10.20, Maxim Yu. Osipov wrote:
> On 5/22/19 9:26 AM, Claudius Heine wrote:
[...]
>>     -> Configuration of the environment is not controllable from the 
>> repository: Installed packages, System configuration (locales), 
>> Distribution, etc.
> 
> In my opinion we need to have some "reference" common (better as minimal 
> as possible) environment, to avoid a zoo of different environments...

Well the more different environments to test against the more you can 
find bugs. If we don't want that, then we should deliver a such and 
environment together with isar.

[...]

> 
>>     -> Cannot be spread over multiple servers
>>     -> Giant log file, that makes it difficult to figure out exactly 
>> which command or test case caused an issue to reproduce that locally
> 
> Your project is configured with -q (quiet) option and doesn't generate 
> huge trace - it becomes verbose only on encountered errors -
> I had no problems with such log file as you can easily find the 
> encountered error and always analyze the build workspace which is not 
> cleaned up for the last build.
> 
> Just have a look at your latest build
> http://isar-build.org:8080/job/isar_claudius_ilbers-ci/64/console
> it took for me 10 seconds to locate the failed recipe.

Well its not always about a failed recipe. The ci_build.sh script now 
contains multiple different calls to bitbake, but we don't see those 
calls in the log. There is also no mention about other calls, like sed 
which changes the configuration.

> 
>>   - Manually triggering of build jobs
>>     -> After pushing of CI branch, build has to be triggered via button
> 
> One may enable such build trigger (I believe that such trigger is 
> enabled for Henning's project). but from my user's experience I prefer 
> to start the build manually.

I normally just push to the ci branch when I want to start tests.

> 
> Of course, overnights builds are started periodically.
> 
> See for details:
> https://wiki.jenkins.io/display/JENKINS/Building+a+software+project
> 
>>     -> Patches on ML should be automatically tested and reported back 
>> to ML (that only makes sense if the build is reliable though)
> 
> Do we really want such feature?
> My concern is that ML will be polluted by such reports...

You are currently testing and reporting back manually, if instead of you 
some bot would do that automatically, then I don't how that would 
increase the noise on the ML. But as I said that only makes sense if the 
false positive and negative rates of CI is lessened.

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de