From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6ED1C433C1 for ; Thu, 25 Mar 2021 11:15:18 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 448C7619E8 for ; Thu, 25 Mar 2021 11:15:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 448C7619E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPNxN-0001FQ-7D for qemu-devel@archiver.kernel.org; Thu, 25 Mar 2021 07:15:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPNwY-0000lA-OU for qemu-devel@nongnu.org; Thu, 25 Mar 2021 07:14:26 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:45797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPNwT-0005eu-Pg for qemu-devel@nongnu.org; Thu, 25 Mar 2021 07:14:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616670859; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=AAhzLWK6a4+EXvN1D5TDf6TOUNStm3nVAYBNy+9XV2w=; b=T48jqRRnikQSKA3inmjsGASuSEcxGppgBTkBddrFAY0iDdR5p6AAUd5RnD373RYChQICbf qKt8TGBTb03swAd9X7pHBirha9gdANTLOgjmtX3guoEMV5xS2vGMMdO0yWUEczzMt4qpuL Ks6+2oZageIlepUgtNS9evrk2Brc3ow= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-302-B82jSOLON7mOXDE8LnQwKg-1; Thu, 25 Mar 2021 07:14:12 -0400 X-MC-Unique: B82jSOLON7mOXDE8LnQwKg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9B91287A82A; Thu, 25 Mar 2021 11:14:08 +0000 (UTC) Received: from redhat.com (ovpn-114-109.ams2.redhat.com [10.36.114.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A2A4619C44; Thu, 25 Mar 2021 11:14:06 +0000 (UTC) Date: Thu, 25 Mar 2021 11:14:03 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Paolo Bonzini Subject: Re: gitlab-ci: Only build /staging branch? Message-ID: References: <2da69b21-ce5e-cae2-68ef-d6e042563a3a@amsat.org> <8ec8b3b7-12b4-b676-630c-972e7038ec7f@amsat.org> <74859ed9-6f93-0b8a-a669-6aef1e164e41@amsat.org> <1a70056b-78b4-c4f4-afc2-044aa499e1c7@redhat.com> <557c7ccc-ce30-a452-8904-590667298389@amsat.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Peter Maydell , Thomas Huth , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , qemu-devel , Willian Rampazzo , Cleber Rosa , Alex =?utf-8?Q?Benn=C3=A9e?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Mar 25, 2021 at 12:05:32PM +0100, Paolo Bonzini wrote: > On 25/03/21 11:34, Peter Maydell wrote: > > It needs to be faster. Mostly I do check the gitlab CI pipeline > > status, but in the run-up to getting rc0 out I stopped waiting > > for the gitlab CI job to finish, because I was continually finding > > that I kicked off a run, my local build-tests would complete within > > an hour or so, and the gitlab CI jobs were still pending, barely > > started, etc. Turnaround on testing a merge must be 90 minutes or > > less, especially during release periods, because there are always > > a huge number of merges that arrive for me to test in the last > > couple of days before freeze. > > Perhaps we could script it so that if the pipeline passes the merge to > master is done automatically. No need to script it, that functionality already exists in GitLab. Push to the staging branch, and open a merge request for applying staging -> master, and enable "merge when pipeline succeeds". You can actually do this all in one command https://docs.gitlab.com/ee/user/project/push_options.html git push \ -o merge_request.create \ -o merge_request.target=master \ -o merge_request.merge_when_pipeline_succeeds \ origin staging The gitlab-ci.yml file could then be configured so that pipeline jobs are associated with a merge request, rather than push event. This will avoid the pipeline being re-run on master after the merge. If you enable "merge trains" option in the repo, then you can even push to multiple branches concurrently, and gitlab will serialize the CI pipelines from each merge request in turn, (assuming no conflicts between then). Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|