Re: Diagnosing CI Failures Question

Re: Diagnosing CI Failures Question

[David Marchand]

Hi Tyler,

On Thu, Mar 16, 2023 at 5:51 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> I am a little lost how I investigate failures that come from the
> ci/intel-Functional tests. I'm still learning and about how to best
> utilize these resources.
>
> Is there a way I can get access to the artifacts from the failure? I
> notice this set of tests is most often the one that fails.
>
> Are the tests run here publicly available somehow? If so I would lobby
> to onboard them to my internal lab to save time by running it prior to
> submission.
>
> I'm also a bit concerned that this exact same failure is produced for
> two entirely separate patch series, but without more detail it's hard to
> tell if that is just a coincidence.

Tyler, I am lost too... those failures started to appear overnight.
This comes from the Intel CI.
I have neither log or nor aware of how to reproduce this.
Let's ask Intel people who were Cc'd on the report...


Daxue, Huang, please, can you enlighten us on what is wrong with this series?
For the context, see:
http://mails.dpdk.org/archives/test-report/2023-March/371507.html


Thanks.

-- 
David Marchand

RE: Diagnosing CI Failures Question

[Huang, ChenyuX]

There is a problem with the ci machine and it has been repaired. No problem with the new report 


Huang, Chenyu
BRS

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, March 17, 2023 1:00 AM
> To: Tyler Retzlaff <roretzla@linux.microsoft.com>; Gao, DaxueX
> <daxuex.gao@intel.com>; Huang, ChenyuX <chenyux.huang@intel.com>
> Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: Re: Diagnosing CI Failures Question
> 
> Hi Tyler,
> 
> On Thu, Mar 16, 2023 at 5:51 PM Tyler Retzlaff <roretzla@linux.microsoft.com>
> wrote:
> >
> > I am a little lost how I investigate failures that come from the
> > ci/intel-Functional tests. I'm still learning and about how to best
> > utilize these resources.
> >
> > Is there a way I can get access to the artifacts from the failure? I
> > notice this set of tests is most often the one that fails.
> >
> > Are the tests run here publicly available somehow? If so I would lobby
> > to onboard them to my internal lab to save time by running it prior to
> > submission.
> >
> > I'm also a bit concerned that this exact same failure is produced for
> > two entirely separate patch series, but without more detail it's hard
> > to tell if that is just a coincidence.
> 
> Tyler, I am lost too... those failures started to appear overnight.
> This comes from the Intel CI.
> I have neither log or nor aware of how to reproduce this.
> Let's ask Intel people who were Cc'd on the report...
> 
> 
> Daxue, Huang, please, can you enlighten us on what is wrong with this series?
> For the context, see:
> http://mails.dpdk.org/archives/test-report/2023-March/371507.html
> 
> 
> Thanks.
> 
> --
> David Marchand

Re: Diagnosing CI Failures Question

[Tyler Retzlaff]

On Fri, Mar 17, 2023 at 04:27:24AM +0000, Huang, ChenyuX wrote:
> There is a problem with the ci machine and it has been repaired. No problem with the new report 

Is there a way to "re-run" existing patch sets through the
ci/intel-Functional tests? or is the only way to re-submit the same
series to dev@dpdk.org?

Additionally, in the case of failures how do we extract artifacts for
diagnosis? for large tree-wide changes it's quite difficult to rely
entirely on code review to guess what caused a failure.

Thanks!

> 
> 
> Huang, Chenyu
> BRS
> 
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Friday, March 17, 2023 1:00 AM
> > To: Tyler Retzlaff <roretzla@linux.microsoft.com>; Gao, DaxueX
> > <daxuex.gao@intel.com>; Huang, ChenyuX <chenyux.huang@intel.com>
> > Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Subject: Re: Diagnosing CI Failures Question
> > 
> > Hi Tyler,
> > 
> > On Thu, Mar 16, 2023 at 5:51 PM Tyler Retzlaff <roretzla@linux.microsoft.com>
> > wrote:
> > >
> > > I am a little lost how I investigate failures that come from the
> > > ci/intel-Functional tests. I'm still learning and about how to best
> > > utilize these resources.
> > >
> > > Is there a way I can get access to the artifacts from the failure? I
> > > notice this set of tests is most often the one that fails.
> > >
> > > Are the tests run here publicly available somehow? If so I would lobby
> > > to onboard them to my internal lab to save time by running it prior to
> > > submission.
> > >
> > > I'm also a bit concerned that this exact same failure is produced for
> > > two entirely separate patch series, but without more detail it's hard
> > > to tell if that is just a coincidence.
> > 
> > Tyler, I am lost too... those failures started to appear overnight.
> > This comes from the Intel CI.
> > I have neither log or nor aware of how to reproduce this.
> > Let's ask Intel people who were Cc'd on the report...
> > 
> > 
> > Daxue, Huang, please, can you enlighten us on what is wrong with this series?
> > For the context, see:
> > http://mails.dpdk.org/archives/test-report/2023-March/371507.html
> > 
> > 
> > Thanks.
> > 
> > --
> > David Marchand
> 

Re: Diagnosing CI Failures Question

[David Marchand]

Hello guys,

On Fri, Mar 17, 2023 at 3:59 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> On Fri, Mar 17, 2023 at 04:27:24AM +0000, Huang, ChenyuX wrote:
> > There is a problem with the ci machine and it has been repaired. No problem with the new report
>
> Is there a way to "re-run" existing patch sets through the
> ci/intel-Functional tests? or is the only way to re-submit the same
> series to dev@dpdk.org?
>
> Additionally, in the case of failures how do we extract artifacts for
> diagnosis? for large tree-wide changes it's quite difficult to rely
> entirely on code review to guess what caused a failure.

Can you reply to Tyler?
Thanks.


-- 
David Marchand

RE: Diagnosing CI Failures Question

[Gao, DaxueX]

Hi Tyler,
Reruns can only be triggered by the ci manager, Submitting a new patch will automatically start testing.
Check for issues from a base branch, such as the dpdk branch, In the future, consider sending the ci/intel-Functional test results of the corresponding branch to the community to facilitate troubleshooting.

Daxue Gao

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: 2023年3月21日 18:11
> To: Huang, ChenyuX <chenyux.huang@intel.com>; Gao, DaxueX
> <daxuex.gao@intel.com>
> Cc: ci@dpdk.org; Aaron Conole <aconole@redhat.com>; Thomas Monjalon
> <thomas@monjalon.net>; Tyler Retzlaff <roretzla@linux.microsoft.com>;
> Mcnamara, John <john.mcnamara@intel.com>
> Subject: Re: Diagnosing CI Failures Question
> 
> Hello guys,
> 
> On Fri, Mar 17, 2023 at 3:59 PM Tyler Retzlaff <roretzla@linux.microsoft.com>
> wrote:
> >
> > On Fri, Mar 17, 2023 at 04:27:24AM +0000, Huang, ChenyuX wrote:
> > > There is a problem with the ci machine and it has been repaired. No
> > > problem with the new report
> >
> > Is there a way to "re-run" existing patch sets through the
> > ci/intel-Functional tests? or is the only way to re-submit the same
> > series to dev@dpdk.org?
> >
> > Additionally, in the case of failures how do we extract artifacts for
> > diagnosis? for large tree-wide changes it's quite difficult to rely
> > entirely on code review to guess what caused a failure.
> 
> Can you reply to Tyler?
> Thanks.
> 
> 
> --
> David Marchand