Re: [DISCUSSIONS] CI build

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

On 5/23/19 10:32 AM, Claudius Heine wrote:
> Hi Jan, hi Baurzhan,
> 
> On 23/05/2019 06.44, [ext] Jan Kiszka wrote:
>>>>   - Not transparent configuration/environment:
>>>>     -> parameters with which ci_build.sh is called are not 
>>>> controllable from
>>>> the repository
>>>
>>> Hmm, the intention actually was that everyone runs the same fixed 
>>> testsuites.
>>> If desired, we could publish the arguments and gradually move them to 
>>> the isar
>>> repo.
> 
> Which is currently not the case, we have a 'normal' build, a 'fast' 
> build, a 'cross' build and a 'repo' build, which can be combined with 
> 'normal', 'fast' and 'cross' IIUC.

Just to clarify.

If the patches I've sent yesterday are accepted the
'normal' build will include

* parallel cross compilation of the set
stretch qemuarm/qemuarm64/qemuamd64/de0-nano-soc/rpi and
buster qemuarm
* sdk creation for stretch qemuarm
* parallel native compilation of the set
stretch qemuarm/qemuarm64/qemui386/qemuamd64/rpi and
buster qemuarm/qemui386/qemuamd64/qemuamd64-buster-tgz/nand-ubi-demo

'fast' build excludes native compilation.

If the extra option 'repro' is enabled, additional separate build
to create/use cached base repo for stretch qemuarm/qemuarm64/qemuamd64 
is launched.

To maximize test coverage I've enabled repro for all your projects in 
Jenkins.

So if the patch set is accepted it would be enough to run 'normal' build 
with 'repro' option: 'scripts/ci_build.sh -q -r'

Regards,
Maxim.


>>>
>>>
>>>>     -> difficult to select which test case should be run
>>>
>>> This is the motivation for Avocado.
>>>
>>>
>>>>     -> Configuration of the environment is not controllable from the
>>>> repository: Installed packages, System configuration (locales),
>>>> Distribution, etc.
>>>
>>> Here the intention has also been to have one standard testing 
>>> environment, and
>>> it is Debian stable + instructions from Quick Start, nothing more. 
>>> I'd welcome
>>> moving to kas + docker. If desired, we could publish the current setup.
>>>
>>> I'd like to have the testsuite be runnable from any CI system with 
>>> the same
>>> script, without arguments. Then people could deploy any system they like
>>> (Jenkins, GitLab, Travis CI, AWS...). The same testsuite should also be
>>> runnable on one's host (already the case with ci_build, 
>>> vm_smoke_test). Under
>>> the hood, every test case should be defined and runnable individually
>>> (Avocado).
> 
> Personally I don't really care about executing the whole CI process 
> locally. I am much more interested in triggering single failed 
> test-cases locally to work on them. So the 'ci_build.sh' is not really 
> useful for me.
> 
> 'ci_build.sh' is just to unhandy to use locally.
> 
> [...]
>>>>     -> Cannot be spread over multiple servers
>>>
>>> Haven't looked at that, ideas welcome. Jan told us he is preparing 
>>> something,
>>> but load balancing would spread multiple pipelines, not tasks within one
>>> pipeline. Depending on the costs, it might or might not be cheaper 
>>> for us to
>>> throw more physical servers on the task.
>>>
>>
>> https://lists.cip-project.org/pipermail/cip-dev/2019-May/002371.html
> 
> Would have been nice to have this cross-posted to this ML as well.
> 
> Will Michael write patches for isar to integrate this, or does he needs 
> anything to do this?
> 
>>>
>>>>     -> Patches on ML should be automatically tested and reported 
>>>> back to ML
>>>> (that only makes sense if the build is reliable though)
>>>
>>> I haven't looked at that. Is there a tool that does this?
> 
> Not really. But I posted a patchwork+jenkins integration howto some time 
> ago: https://that.guru/blog/patchwork-and-ci-in-a-tree/
> 
>>>>   - Logs aren't public accessible
>>>
>>> Logs are accessible with authentication. Jenkins has public mode, but 
>>> it lists
>>> the users publicly, that is why we haven't opened it till now. If 
>>> desired, we
>>> could look at that. Is it that high-priority, given that all major 
>>> contributors
>>> here have access?
>>>
>>
>> Let's stop wasting thoughts on legacy Jenkins, rather discuss how we 
>> can move on to gitlab-ci, if something is missing there etc.
> 
> I can only figure out what is missing after I tried it out.
> 
> 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