From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 84D403861C5F for ; Thu, 1 Jul 2021 12:06:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 84D403861C5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id A27021933; Thu, 1 Jul 2021 14:06:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kIOdhEEnnmf; Thu, 1 Jul 2021 14:06:16 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p50854661.dip0.t-ipconnect.de [80.133.70.97]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 1DF2B1E81; Thu, 1 Jul 2021 14:06:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1625141176; bh=qstcmzJen+oTr5Fd1QjbdB7gQSITsjZjjNsrmfHEdXg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=k5QqwLAFyrvQeR6zPL68r+kUstnOI+hLseC80WDEHQ84pU3/cZET1X+4RoTksYua7 s+mVM08ADUvFkxp405IdGZosH7y/ilV04XIlf0esJkGO2QfOFYFxU/GK0ZLr9+zIa1 t2rFkVkz/ycLd98c2KhC7zkhCkNzpFPqMxhzJOAq+tedWArJDMSydzNg/TApx2Sev0 FE0/km5iBG8UHl8PbPpPE+OueIvPOfK3EjnCWQxL00S3NF4koBPRZREpLkgYNCgENk EbL+VYDcq33qHprpo93LjCPUm37QaUpSPmfO+N4XFXIz25chAoQ/EAWl7sbss4U4Cs vdZ1pZbFIpMeQ== From: Rainer Orth To: Luis Machado Cc: Luis Machado via Gdb Subject: Re: [RFC] Proposal for hosting GDB CI builds References: <7bfae273-3887-30c8-dc65-94d5b177db56@linaro.org> <0e30f5d9-9f2f-05bd-1d02-30424017c6d7@linaro.org> Date: Thu, 01 Jul 2021 14:06:15 +0200 In-Reply-To: <0e30f5d9-9f2f-05bd-1d02-30424017c6d7@linaro.org> (Luis Machado's message of "Thu, 1 Jul 2021 08:48:28 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3787.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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 12:06:27 -0000 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. > 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. Documenting the set of necessary packages is similar to what one needs for manual GDB builds, just a bit more formalized. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University