From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2DE80A0C51 for ; Thu, 10 Jun 2021 10:13:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 26FC44067C; Thu, 10 Jun 2021 10:13:21 +0200 (CEST) Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by mails.dpdk.org (Postfix) with ESMTP id 9D8134003C for ; Thu, 10 Jun 2021 10:13:19 +0200 (CEST) Received: by mail-ej1-f44.google.com with SMTP id g8so42771655ejx.1 for ; Thu, 10 Jun 2021 01:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3yluWl7DDVmFiigdmuQAIc0p7pgByvWjOp9TV+Xecc4=; b=Wb6cMv4lfOEJ+2U1sTZO6txNE8ezYEKcZEDN1Ovt/Zyb8R2T1AEJ8rQeW2niwCb0QH 4kIXFkREDAdYiQWtbqjj9Uz2WiaaxeWoJ2UwvSOdF3XCMzFFLubAxQ117pikGNJj9PRX vCcgs1UG4ndGy+zYjh68FzablIr6GhiLeUApg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3yluWl7DDVmFiigdmuQAIc0p7pgByvWjOp9TV+Xecc4=; b=byF2ixhp+uK3Sh2z7dwzIlPxJo6TM2hB5QMdZsfcnjdw/F5OvDi1quzjGuqLsQDZKK l4k0z9O0em1MaMEnrdFvwECZcikC/k7axQS8CJQAR01AU8E/C+tVn+TI4Uyj+imCEgb0 Am8zobqMeMRxA3kppHmZEP8uCzFErUgOeCkm2SUeAgOUwBwraymL+ZWr4faQGh09hXVU 2+pVk0IVCv/zzyy7sndb6uN63tb/lY1ezkoLaOXMS1JAzFtWbY4AOdJvXIJVADwmNiYw +dh14s7Gh+BGuCPWj6z1xBwVrKQi7NV88XRsZHQrm7Qr64nsMfEc/HMURGxTm0NS4e2k kQ8A== X-Gm-Message-State: AOAM532PU+ola4MezI4+rTMmhVG2YUVMKaAJpB0o+eUsDpVBZvnReC9S iSR2VLjq1MikmKq1UP5ekzhGJTDlySeXUVwv8ea3sA== X-Google-Smtp-Source: ABdhPJyWFbOOYmz8rGgyCCsAG903Uk6FcShrxT+q9S0A0qUWRZeeWqyS4ujz53ahirNX4+4Hxndbf5Od9MTh+dKsrRw= X-Received: by 2002:a17:906:29c8:: with SMTP id y8mr3398036eje.312.1623312799338; Thu, 10 Jun 2021 01:13:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lincoln Lavoie Date: Thu, 10 Jun 2021 04:13:07 -0400 Message-ID: To: David Marchand Cc: Brandon Lo , dpdklab , ci@dpdk.org, Aaron Conole , Thomas Monjalon , Ray Kinsella , Dodji Seketeli Content-Type: multipart/alternative; boundary="000000000000c3adf405c464f645" Subject: Re: [dpdk-ci] [dpdklab] ABI test failing for openSUSE and Arch Linux X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Sender: "ci" --000000000000c3adf405c464f645 Content-Type: text/plain; charset="UTF-8" Hi David, I think yes. What Brandon was referring to is linking the process we use to refresh the container images and the rebuild of the ABI references, so one triggers the other. What happened with the failure was the container images got rebuilt, and that pulled in updates that change the ABI output (in valid ways), which then "look like" a failure or change from the reference that was previously saved off. We save off older versions of the container images (i.e. things are tagged), so we can always roll back if need to. ABI reference generation should be deterministic on that container image, so we don't save "versions" of those references. Cheers, Lincoln On Thu, Jun 10, 2021 at 4:02 AM David Marchand wrote: > On Wed, Jun 9, 2021 at 5:07 PM Brandon Lo wrote: > > To streamline this entire process, we are working on a job or pipeline > > to automate refreshing all of the images and recreate the ABI > > references. > > I understand the motivation, but will we have a clear idea of which > ABI reference has been used and how to reproduce its generation (sha1, > toolchain, libc, libabigail and such packages versions, version of the > script generating the reference) ? > If something breaks later and we don't know clearly how/if a reference > changed, it will be a pain to analyse. > > > -- > David Marchand > > -- *Lincoln Lavoie* Principal Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m) --000000000000c3adf405c464f645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi = David,

I think yes.=C2=A0= What Brandon was referring to is linking the process we use to refresh the= container images and the rebuild of the ABI references, so one triggers th= e other.=C2=A0 What happened with the failure=C2=A0was the container=C2=A0i= mages got rebuilt, and that pulled in updates that change the ABI output (i= n valid ways), which=C2=A0then "look like" a failure or change fr= om the reference=C2=A0that was previously saved off.

We save off older versions of the container ima= ges (i.e. things are tagged), so we can always roll back if need to.=C2=A0 = ABI reference generation should be deterministic on that container image, s= o we don't save "versions" of those references.=C2=A0=C2=A0

Cheers,
Lincoln

On= Thu, Jun 10, 2021 at 4:02 AM David Marchand <david.marchand@redhat.com> wrote:
On Wed, Jun 9, 2021 at 5:07 PM = Brandon Lo <blo@iol= .unh.edu> wrote:
> To streamline this entire process, we are working on a job or pipeline=
> to automate refreshing all of the images and recreate the ABI
> references.

I understand the motivation, but will we have a clear idea of which
ABI reference has been used and how to reproduce its generation (sha1,
toolchain, libc, libabigail and such packages versions, version of the
script generating the reference) ?
If something breaks later and we don't know clearly how/if a reference<= br> changed, it will be a pain to analyse.


--
David Marchand



--
Lincoln Lavoie
Prin= cipal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, = Durham, NH 03824
+1-603-674-= 2755 (m)

--000000000000c3adf405c464f645--