Opened 10 years ago
Closed 23 months ago
#45010 closed enhancement (fixed)
RFE: stop "port test" immediately if no test phase defined
Reported by: | dstrubbe (David Strubbe) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.3.1 |
Keywords: | Cc: | cooljeanius (Eric Gallager), kurthindenburg (Kurt Hindenburg), larryv (Lawrence Velázquez) | |
Port: |
Description
If you run "port test" on a port, it will go through all the phases of checking dependencies, fetch, extract, configure, and build before finally giving an error like:
Error: org.macports.test for port scalapack returned: scalapack has no tests turned on. see 'test.run' in portfile(7)
It would be convenient if this check could be performed immediately, before carrying out any of the other steps (which might be quite time-consuming).
Attachments (2)
Change History (14)
comment:1 Changed 10 years ago by cooljeanius (Eric Gallager)
Cc: | egall@… added |
---|
comment:3 follow-up: 6 Changed 10 years ago by kurthindenburg (Kurt Hindenburg)
I agree. It is trivial to check for 'target equal test' in macports1.0/macports.tcl before or after installing dependencies. However, I'm at a lost of how to get the "test.run" option from the portfile. If someone can point me in the correct direction, I'll give this a shot.
comment:5 Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Here's another try - I'm not sure if the 'info level' is the way to go here - looking for feedback.
Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Attachment: | portmain.tcl.diff added |
---|
comment:6 Changed 9 years ago by neverpanic (Clemens Lang)
Replying to khindenburg@…:
I agree. It is trivial to check for 'target equal test' in macports1.0/macports.tcl before or after installing dependencies. However, I'm at a lost of how to get the "test.run" option from the portfile. If someone can point me in the correct direction, I'll give this a shot.
I agree with jmr that the test should be in macports1.0/macports.tcl. To get the value of test.run
from the Portfile context, you can use $workername eval [list option test.run]
. In theory, you could also use the _mportkey helper to get variables from the Portfile context, but that's currently broken with non-trivial variable names:
% set key test.run test.run % $workername eval [list set $key] yes % _mportkey $mport $key can't read "test": no such variable %
comment:7 Changed 9 years ago by neverpanic (Clemens Lang)
I've fixed the problem with _mportkey
in r140015. You can also use _mportkey $mport test.run
now.
comment:8 Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Thanks Cal - any comments about this implementation?
Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Attachment: | mp-test.diff added |
---|
comment:9 Changed 9 years ago by jmroot (Joshua Root)
You shouldn't throw an error in mportexec, it's meant to return 1 on failure. After the log has been pushed, you need to clean up by popping it before you return. (So maybe do this check before pushing the log.) The comment talks about dependents, which doesn't make much sense.
Maybe also consider whether this case should be considered a failure at all. Does it make more sense to say "We successfully ran all 0 tests that this port has" rather than "We failed to run any tests"?
comment:10 Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Thanks
Since the user specifically asks for 'port test' I think it should fail if no tests are enabled.
I don't really like the the line to report a bug.
sudo port -v test py27-queuelib Error: py27-queuelib has no tests enabled; select another target. Error: Follow http://guide.macports.org/#project.tickets to report a bug. Error: Processing of port py27-queuelib failed
comment:11 Changed 4 years ago by kurthindenburg (Kurt Hindenburg)
I forgot all about this issue - https://github.com/macports/macports-base/pull/185
comment:12 Changed 23 months ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Cc Me!