New post
Question
· Aug 12, 2022

Return Error Code After Unit Tests to CircleCI Job

#DevOps #Testing #InterSystems IRIS for Health

Does anyone have experience with CircleCI or really any automation tool using %UnitTest?

I have built my app and ran my unit test in a Docker container automated by CircleCI.  However, after many of the tests failed I see:

How do you halt out of the IRIS session and return an exit code to the shell?

I have a script in my repo that I pass into IRIS after CircleCI does the code checkout

iris session IRIS < inFile

Am I trying to approach this the wrong way?  Should I be writing test output to a file or something?  Even so, I still need a way to say to CirclCI "unit tests failed, so don't do the next step of building the code on the actual server" and to send out alerts so we know it failed.  

Discussion (8)2
Log in or sign up to continue
Michael Davidovich · Aug 12, 2022

@Timothy Leavitt 

Another question popping up.  How do I access the test result on the command line to see if it failed?  When I run DebugRunTestCase, the the URL spits out with the result index in it.  I created an instance of Manager and then ran the method but I don't seem to get any properties or output that say "this failed."

Thoughts here?

0 0
Timothy Leavitt · Aug 15, 2022

@Eduard Lebedyuk it depends on the caller. In a CI process I could imagine doing different error handling for failed compilation vs. failed unit tests, this would be a way to signal those different modes of failure.

I've taken/seen approaches that are more shell-centric vs. more ObjectScript-centric which would be a driver for this being useful. With the package manager it's generally simpler to wrap things in <Invoke> or resource processors and then call IRIS with individual zpm commands (i.e., load then test) from CI. For some of my pre-package manager CI work we've had a big ObjectScript class that wraps all the build logic, running different sorts of tests, etc. In this case it would be useful to indicate the stage at which the failure occurred.

Regardless, $System.Process.Terminate is simpler to manage than "flag files" for sure, which would be the next best alternative. (IIRC in old days, maybe just pre-IRIS, there were Windows/Linux differences in $System.Process.Terminate's behavior, and that led us to use flag files.)

0 0