From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6693749539433611264 X-Received: by 2002:a1c:a958:: with SMTP id s85mr6997756wme.144.1558524523500; Wed, 22 May 2019 04:28:43 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:2304:: with SMTP id 4ls587113wmo.4.canary-gmail; Wed, 22 May 2019 04:28:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqwCbVt2q1sHWGi5Pbcw3gQUcBLEXCJROefhhh5ivg4duNkmMma9wwYC3B55+QB4jcX9LsPw X-Received: by 2002:a1c:9c02:: with SMTP id f2mr7314850wme.8.1558524523052; Wed, 22 May 2019 04:28:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558524523; cv=none; d=google.com; s=arc-20160816; b=tpCDdew7u32OSdJdzblG6QWgixBnexiWnsjFRaaL62fVp+wpVaNjgBFtFhJ0RTlVQ6 bn8/xgRI4LYBDZ95o485FrqE9tQ8zuyjO9OVH6qQ5FJziAj0ZUUCk85Q88b5tMOxilOd IX/mYL8eFn6wa727VZ2PA5ws+mdFwWpaWoEZlPHESmk1qIzSt1ufgX8IASm5nfdjV3h4 +/oNua2UM2iykAx5hjRdfIH8mK2crbQt0AyvBFkt/yL+EgqWz05+BtflTBbRGD2Mc+Tg XSq+/HY0iwxvqaV7qs+pg7rs9/NJKt12ebZ2qog9aJ8VeE0IvAFv3JvEJWB21dUr221M 6UVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=XftG+T+Gk3nd7w7I2nfgKdmSgyMxRLQSW4XeHC1rKS8=; b=ZxpojKh0E7n3s3HhTq4m0Ye6sjquSEr4y5ILXbkiH3gPm6gDVlaZTIn5TVCzDPOHVi PeU7eNOvqP71/JhT3LdQJc+EPmk+bGSTtEepz4ybfgKhyzH6CFcgsthk/P70pa2J18Di gtzhUqh7AdJVsVQw1x9x0QRhibQcOoCQ//+TYRE9EMpzdAqfHbKUtZwrwDPGBSlf2MKL EG67Ba9tFDDgX0igs05cWXjE/0dif5iC4X1jYDXcpndPyTzQCZASM/GjSFgSl5FwmQga Uh4YcIEuIS4DWtgtv0dROg/GAwvPgTbjAQR/II8rznIznWm5964TyMtdYs7howH96r9R enVA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id q11si614028wrj.2.2019.05.22.04.28.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 04:28:43 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x4MBSgOi008359 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 May 2019 13:28:42 +0200 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x4MBSgG0005731; Wed, 22 May 2019 13:28:42 +0200 Subject: Re: [DISCUSSIONS] CI build To: "Maxim Yu. Osipov" , isar-users References: <5128c754-55f8-924b-365c-2d529131bd3a@ilbers.de> <16e80d33-4f24-8b5a-de02-c02a90cc2c77@siemens.com> <57463c63-9747-126f-4b98-dc042f2b674a@ilbers.de> From: Claudius Heine Message-ID: <80ac809b-384a-7654-0a13-2723be6eedb7@siemens.com> Date: Wed, 22 May 2019 13:28:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <57463c63-9747-126f-4b98-dc042f2b674a@ilbers.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: I+XBa5vXJfw/ 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