[dpdk-ci] Could we have some agreements on the CI then discuss the opens

Thomas Monjalon thomas.monjalon at 6wind.com
Tue Nov 15 10:43:03 CET 2016


Hi,

2016-11-15 09:07, Xu, Qian Q:
> Hi, all
> I just think that if we can have some agreements on the DPDK CI tasks firstly, then discuss about the open list.

Sorry, I don't understand what you mean.

> Possible agreement parts:
> 
> 1.      Schedule tool: Jenkins.
> LF has the Jenkins as the schedule tool. So I wonder if all agree on this schedule tool for scheduling build and regression test.

The schedule tool must be a personal choice for each test instance.
Are you talking about the reference lab?

> 2.      Create per patch check(patchcheck and build) by using Jenkins to trigger
> For each patch check, currently we cover the Patchcheck and build.
> I noticed Thomas has a separate mail about checkpatch, so does it mean we can remove patchcheck from the build test?

Yes
The email checkpatch at dpdk.org is the address of this test instance.
If you send a patch directly to this instance, you will receive a private report.
It could be a good idea to do the same at Intel so we can test the compilation,
especially with ICC, before sending a public patch.
And this feature should be documented somewhere.

> For build test, Intel can provide Intel IA based per patch build report. If there is common format, we can follow it.

Now that the release 16.11 is done, I'll work on sharing some scripts.

> 3.      Create daily or weekly functional/build regression test based on git tree, also using Jenkins to trigger
> For the functional/build regression tests, Intel has already sent out the daily build and functional regression test. If there is common format, we can also follow it.
> Besides Intel, I have also seen the IBM's daily build report. Any others want to publish the daily/weekly functional regression tests?
> 
> Opens:
> 
> 1.      Centralized or distributed performance lab. Is the decision more dependent on budget or the thoughts?

Anyway the per-patch checks will be distributed and aggregated in patchwork.
If we build a reference lab inside Linux Foundation, it will be part of the
distributed CI.
So your question should be:
Are we going to have a budget for a reference lab?
Which tests will be run in this CI instance?

> 2.      Performance report center. Do you want to publish the performance report and which is the preferred format?
> 
> 3.      The code review tool is still by mailing list. Is it the final decision?
> 
> 4.      How about the central bug system? Do we want to have one?

+1, I commit to have a central bug tracking on dpdk.org during December.

> Proposal:  Could we have a CI weekly sync-up meeting for discussion only on CI? If most people on the mailing list from EU and PRC, then we could find a more friendly time for PRC people.

If interested people are Chinese and French, it would be a good idea to have
an IRC meeting.


More information about the ci mailing list