Re: [DISCUSSIONS] CI build

["Maxim Yu. Osipov" <mosipov@ilbers.de>]

On 5/22/19 11:10 AM, Claudius Heine wrote:
> 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.

Please provide your detailed proposals how this can be formalized as
there is an indefinite number of environments.
Again, I vote for some common "reference" environment.


> [...]
> 
>>
>>>     -> 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.

OK, I'll add `set -x` in ci_build.sh.

> 
>>
>>>   - 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.

I've enabled the corresponding options for your projects - please try.

> 
>>
>> 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.

Manual work is unavoidable as sometimes patches are not merged properly.
I'll enable reporting to ML when I push a patch set to maintainers 
branches for CI.

Regards,
Maxim.



> 
> regards,
> Claudius
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov