X-Recipient: archive-cygwin AT delorie DOT com X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 507F83858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dinwoodie.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dinwoodie.org Date: Wed, 16 Feb 2022 10:40:43 +0000 From: Adam Dinwoodie To: cygwin AT cygwin DOT com Subject: Re: Trouble trying to compile apache2 Message-ID: <20220216104043.v5epaz37dk7zbhx4@lucy.dinwoodie.org> References: <20220215123941 DOT yxesbunapq3gaxgq AT lucy DOT dinwoodie DOT org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, PDS_RDNS_DYNAMIC_FP, RDNS_DYNAMIC, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Tue, Feb 15, 2022 at 04:50:22AM -0800, Russell VT wrote: > Thanks for the clarification, Adam. > > I've been meaning/wanting to step up and take care of some Cygwin packages, > given that it's generally my Unix after from my desktop environment sort of > arrangement ... and, well, I have a Jenkins server that has some free > cycles on it (particularly for things like nightly, off-hours > builds/pipelines). > > TLDR; I will start digging in to it, myself... may not have too much spare > time, at least this week, until the weekend. FWIW, there's already a bunch of automation available, although it's all being actively (if slowly) developed, which in particular means the documentation is lagging behind the actual current implementations. But you might be able to make use of the existing infrastructure to get a head-start without needing to bother with your own Jenkins servers &c. Some folk are using Scallywag, which uses GitHub Actions to run things at https://github.com/cygwin/scallywag, and (I think) gets automatically triggered when maintaners commit to the repos at https://cygwin.com/git-cygwin-package, although I don't think you'll be able to do that until you're already the official maintainer for a package. Getting to that point will probably need you to do your own builds locally first. I'm doing things slightly differently, and using GitHub Actions in my own repositories. I've been actively working on improving the automation over the past few weeks; the closest I have to best practices (at least for my own purposes) is currently spread over the following two repositories, and I'm planning to produce a more-or-less standardised boilerplate automation across all my packages over the coming weeks. See, in particular, the contents of the .github/workflows directories for the actual automation configuration. https://github.com/me-and/Cygwin-AsciiDoc/tree/next https://github.com/me-and/Cygwin-Git/tree/next Inevitably a bunch of other maintainers will have their own way of doing things; I think Scallywag is the closest thing we have to a common CI/CD setup. But hopefully some of this might give you pointers to CI/CD tools that require minimal setup and won't even cost you time on your own build servers. Or, at the very least, ideas about what you'll need to do for your own automation. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple