Re: [DISCUSSIONS] CI build

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

Hi Maxim,

On 22/05/2019 11.50, Maxim Yu. Osipov wrote:
> 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.

For me containers have proven to provide ways to easily provision and 
configure the content while having a reasonable hit on performance.

> Again, I vote for some common "reference" environment.

If you want to go that way, then maybe choose the kasproject/kas-isar 
docker container as the reference environment, since that is used by 
most contributors when developing AFAIK. And then we can point to that 
container in the documentation as well, so nobody will try to run isar 
in a different 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.

Hopefully that will not be too noisy on the log.

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

Thanks. But I think I should now have two branches for each different 
build parameter set. So that I don't trigger both builds just for one push.

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

Can you make it so that it emails with the correct email 'in-reply-to' 
header, so it lands in the right thread of the patchset? Otherwise 
ordering that will be annoying.

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