Experimental Physics and
Industrial Control System

"Johnson, Andrew N. via Core-talk" <[email protected]> · Fri, 9 Nov 2018 05:07:18 +0000

Hi Dirk,

If you have (or can install) GNUmake 4.x there is a -O option that separates the output from different builds. This makes parallel jobs reasonable to use.

The ‘tapfiles’ target was added in Base-3.14.12.6 and is documented in the release notes for that release. That is generally the only place I document build system features because the AppDevGuide chapter is so old. After ‘make -O -j tapfiles’ you can do ‘make test-results’ to have the results printed, or ‘make junitfiles’ to feed junit results into a Jenkins plugin if you don’t like the tap plugin. Those are also documented in the release notes...

- Andrew

-- 
Sent from my iPad

> On Nov 8, 2018, at 12:52 AM, Dirk Zimoch <[email protected]> wrote:
> 
> 
> 
>> On 02.11.2018 17:43, Johnson, Andrew N. via Core-talk wrote:
>> Hi Dirk,
>>> On 11/02/2018 05:01 AM, Dirk Zimoch wrote:
>>> It seems I have a hanging test in 3.15 as well
>>> 
>>> make[3]: Entering directory
>>> `/jenkins/workspace/EPICS-3.15/src/ioc/db/test/O.RHEL7-x86_64'
>>> perl -CSD -MTest::Harness -e 'runtests @ARGV if @ARGV;' dbShutdownTest.t
>>> dbPutLinkTest.t dbLockTest.t testdbConvert.t callbackTest.t
>>> callbackParallelTest.t dbStateTest.t dbCaStatsTest.t scanIoTest.t
>>> dbChannelTest.t dbChArrTest.t chfPluginTest.t arrShorthandTest.t
>>> recGblCheckDeadbandTest.t testPutGetTest.t
>>> dbShutdownTest.t ........... ok
>>> dbPutLinkTest.t ............ ok
>>> dbLockTest.t ............... ok
>>> testdbConvert.t ............ ok
>>> callbackTest.t ............. ok
>>> callbackParallelTest.t ..... ok
>>> dbStateTest.t .............. ok
>>> dbCaStatsTest.t ............ ok
>>> Starting iocInit
>>> iocRun: All initialization complete
>>> Starting iocInit
>>> iocRun: All initialization complete
>>> [Hangs here]
>> That's scanIoTest, which has had problems on various architectures and
>> was completely rewritten by Michael for the 3.16 branch in 2015. His
>> 3.16 version probably won't back-port easily to 3.15 though, it uses
>> some 3.16-only infrastructure IIRC. If it's causing problems you might
>> want to just disable that test; I'm not sure what else to recommend.
> 
> Most of the time it works. In particular when I had re-run the tests manually without even re-compiling, there were no problems. Only last week it was hanging for 3 days once until I aborted it.
> 
> Thus I was suspecting some interference like two tests trying to use the same port at the same time.
> 
>>> If I am running the tests for different EPICS versions on the same
>>> Jenkins server, can they destructively interfere if the tests happen to
>>> run at the same time? In that case I better change the Jenkins
>>> configuration to use only 1 worker.
>> They shouldn't do, although you might want to set EPICS_CA_ADDR_LIST to
>> localhost and EPICS_CA_AUTO_ADDR_LIST to NO just in case. I usually run
>> the tests in parallel (make -j4 tapfiles) with no problems, but I'm not
>> running tests on multiple host-arch's on the same CPU.
>> - Andrew
> 
> I use the different workers to run 3.14, 3.15, 3.16, and 7 in parallel. I do not use 'make -j' because that makes the output in the console log more readable. Thus I do not suspect a problem with multiple host archs but with multiple EPICS versions running at the same time.
> 
> I did not know about the "tapfiles" target and even now that you mention it I cannot find documentation about it. I was running "make runtests" but found that Jenkins cannot find failed tests this way. What should I use instead?
> 
> Dirk

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System