Re: [DISCUSSIONS] CI build

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

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.

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

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