Re: cygport test has zero exit status on failures

[ASSI <Stromeko@nexgo.de>]

Jason Pyeron writes:
> If I have a CI build for *.cygport - is it expected to have
> conditional logic based on which package is being processed?

Not necessarily, I understand you were talking about default behaviour
and how the current default doesn't match your / your CI's expectation.
To reiterate, you can already do what you want by defining your own
src_test function and this behaviour becomes part of the package
definition then.

> I thought was the purpose of the cygport file [1] was to contain only
> the compiling, testing, and installation instructions, just like
> portage [2].

I consider cygport its own thing by now that is not actively
synchronized to what portage ends up doing.

> In any case the all or all-test does not execute the test step, so the
> customization of the src_test does not impact the default behaviors.

That's beside the point.  We were only talking about the test behaviours
or at least I was, anyway.  Now again, if you do that in the cygport
file you mix that expectation of getting a return value (that really
comes from the way you run cygport in the CI and determine the test
status) with the package definition.  If you force that to satisfy your
CI requirements, you also break the flow for folks who (as an example)
rather do

cygport $p finish prep compile inst test pkg

because a test fail would now error out before getting to the packaging
step.  Which is why I was musing that your preference in how to treat a
test fail should really be injected from the run-time environment rather
than the package definition.  Once that mechanism is in place I can also
start writing my own src_test functions that switch their behaviour
depending on that setting so that these package definitions would work
in either environment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables