Re: [DISCUSSIONS] CI build

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

On 5/22/19 9:26 AM, Claudius Heine wrote:
> Hi,
> 
> we discussed some issues with the CI offline.
> 
> Here are my issues of the current CI with Jenkins in text:
>   - Unreliable build:
>     -> Network and other unrelated issues to the patch
>     -> Contains expected to fail tests
>   - Not transparent configuration/environment:
>     -> parameters with which ci_build.sh is called are not controllable 
> from the repository
>     -> difficult to select which test case should be run

Yes. that's why we are going to migrate to avocado test suite.

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

>   - Just one giant build process
>     -> Takes a long time

I fear that it can't be avoided for such kind of build systems - several 
months ago we upgraded/tweaked the server and whole CI build itself 
takes now around 1 hour (which is acceptable in my opinion).
We are improving now smoke test launching.

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

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

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

>   - No "test everything" (acceptance test) build job

I'll introduce such acceptance test.

>   - Logs aren't public accessible

I think that Baurzhan may comment this.


Regards,
Maxim.

> 
> Anyone has other issues or comments?
> 
> 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