From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 60CE33861C5F for ; Thu, 1 Jul 2021 13:10:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 60CE33861C5F Received: by mail-pg1-x52a.google.com with SMTP id e33so6055325pgm.3 for ; Thu, 01 Jul 2021 06:10:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=86TD+qL/xYZez7sQRiagWyQAX5I83r/7k12/y5U7x7k=; b=eff7DCQRLVvstXzBycb2VsyJ3BcVw2lRJ5U3ygiNrWxJFcOvh3ML3P0Gzgs6m+Tujs pFdq/FDXDQuVzs2iqywEf4sgGXah0Vl51BxUEV6aG9y/iNqlrmB5rGF7gPmCjp7XkSLC OkBzURuqqLhasQPtT/H7qXPX7XbND6bNBQr+SKDZaUCstW6yyYZZ7ACCL3/mhaarPGBh ssamPimvC1YQVsn48HOd3li9idBuzkVC1HMN/HUlV4ptz1TyLV0sMA0xcsZ2X1HkbDEr tISOJqwPF/gjf3Fnw1M+hmZuvik9yTGOki8nAiH8mctb0eiYmWFwWmiQ12TfeykUWT1D +zHA== X-Gm-Message-State: AOAM530gnQ37btHpsW2PUehEjr4PMpKgfubdu8QKyJ8GEKjoI5CGTafM G8KeBZfZkIVUCJlU2E9h4z8sBfCNGMa6Yg== X-Google-Smtp-Source: ABdhPJxjPpUnw+6zon/HHPRuzbqvo50RxiSZr12JOOX5d3QOL+3N5RmaAWgRaYHyHlxABwvDXcPR9A== X-Received: by 2002:aa7:904e:0:b029:305:c072:b643 with SMTP id n14-20020aa7904e0000b0290305c072b643mr40951379pfo.13.1625145053387; Thu, 01 Jul 2021 06:10:53 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:1e6a:d86b:249c:eb1d:ab69? ([2804:7f0:4841:1e6a:d86b:249c:eb1d:ab69]) by smtp.gmail.com with ESMTPSA id c20sm25858805pfp.203.2021.07.01.06.10.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jul 2021 06:10:53 -0700 (PDT) Subject: Re: [RFC] Proposal for hosting GDB CI builds To: Rainer Orth Cc: Luis Machado via Gdb References: <7bfae273-3887-30c8-dc65-94d5b177db56@linaro.org> <0e30f5d9-9f2f-05bd-1d02-30424017c6d7@linaro.org> From: Luis Machado Message-ID: Date: Thu, 1 Jul 2021 10:10:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 13:10:57 -0000 On 7/1/21 9:06 AM, Rainer Orth wrote: > Hi Luis, > >>>> Linaro can take care of providing builders and build jobs for ARM. Other >>>> architectures would be handled by their respective contributors. Those >>>> contributors can write jobs and plug builders as needed. >>> thanks for coming forward with this: this is very welcome, given how >>> easy it is to miss build failures and other issues especially on >>> not-so-common targets. >>> However, is there any documentation on setting up new builders? I've >>> never dealt with Jenkins before, and from glimpsing over the docs some >>> time ago when Jeff Law talked about extending this GCC builders to a >>> wider range of architectures left me completely at a loss: the whole >>> thing felt like a total moloch with an incredible range of abilities, >>> but little to no guidance on how to start. If the GDB CI wants to >>> extend beyond a Linux-only range of targets, I believe considerable >>> documentation is necessary to make this happen. >> >> I know the feeling. I've been there myself as Jenkins is indeed a very >> flexible tool. And I don't, by any means, claim to be an expert on >> dealing with it. >> >> Usually what I do is to peak at the documentation and at what others have >> implemented. Then I work on extending/modifying things to my needs. > > same here. In the case of the GDB and LLVM buildbots there was some > documentation to start from, although I'd still to figure several things > out by myself. Fortunately, the buildbot docs aren't that forbidding ;-) > >> The GDB build job (currently running for aarch64/armhf/x86_64) I put >> together is here: >> >> https://git.linaro.org/ci/job/configs.git/tree/tcwg-gdb.yaml > > Fine, thanks. > >> But I expect we will have to adjust this to make it a bit more generic so >> other architectures can use it. > > I'll certainly have look. If nothing else, it's a start and way way > easier than having to start from scratch. > >>> Besides, I seem to have glimpsed from the Linaro instance that the >>> builders use Docker. Is this a requirement or just a convenience? I'm >>> asking because there's no current Docker port to Solaris (there used to >>> be one based on zones, but it's no longer maintained) and the >>> buildbot-based builders I'm running (for both LLVM and GDB) do fine >>> without. >> >> That is a convenience so we can share hardware resources. It is possible to >> use real hardware to run the jobs. One may need to adjust the > > For my existing buildbots, I let them run inside Solaris zones (the > equivalent of Linux containers) and could use ressource control features > to provide additional containment (e.g. cpu, memory use) if need be. > That's good. One other benefit of using docker images is the consistency between runs. You have control over the exact distro + set of packages that are installed in the image, so you have a better chance of being able to repeat a run. >> configurations a bit (distro, packages etc), but a job can automate some >> of that. Details about distros to use and packages to install still need to >> be investigated/discussed. > > In my case, I start from a configuration matching what I use for manual > GDB builds, afterwards keeping the system up to date about once a > months. This makes the host somewhat a moving target, but the rate of > chance hasn't ever caused problems. I think that's reasonable. Regular updates shouldn't cause breakage to GDB. If they do, that's a sign that something was/got broken anyway. > > Documenting the set of necessary packages is similar to what one needs > for manual GDB builds, just a bit more formalized. We maintain a set of required packages in a separate file. That file gets loaded and processed so we are sure all the dependencies are met. So coming up with a similar non-docker-based mechanism shouldn't be hard.