Project

General

Profile

Feature #18270

Have test_runner find the test configuration file from the source directory

Added by Gianluca Petrillo over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
11/14/2017
Due date:
% Done:

100%

Estimated time:
Duration:

Description

The standard way of installing the test information, via install_scripts(AS_TEST), flattens all the content into the test subdirectory of the UPS product.
The test_runner script will look for it there, at ${*_DIR}/test/ci_tests.cfg.

When running test_runner from MRB build area, with development setup, the variables *_DIR points to the source tree, and the actual path of the test configuration file is (at least, by LArSoft convention) ${*_DIR}/test/ci/ci_tests.cfg.
While it is possible to explicitly tell test_runner where the configuration file is (--config option), I would like it to look for the configuration also in ${*_DIR}/test/ci/ci_tests.cfg as a fallback choice if the current ${*_DIR}/test/ci_tests.cfg fails to match:

--- test_runner
+++ test_runner
@@ -201,10 +201,12 @@
         # look for ci_tests in anything that is setup(?)
         for k in os.environ.keys():
             if k.find("_DIR") > 0:
-                fname = os.environ[k] + "/test/ci_tests.cfg" 
-                if os.path.exists(fname):
+                for subdir in ( 'test', 'test/ci', ):
+                    fname = os.path.join(os.environ[k], subdir, "ci_tests.cfg")
+                    if not os.path.exists(fname): continue
                     if self.debug: print "Found config: ", fname
                     self.config.read(fname)
+                    break

     # our config file has [test name] or [suite name]
     # we operate on 'name', so look for either one for now...
Warning: untested code!

History

#1 Updated by Vito Di Benedetto over 1 year ago

  • Status changed from New to Assigned
  • Assignee set to Bruno Coimbra

#2 Updated by Bruno Coimbra over 1 year ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

The test_runner will now look for ci_tests.cfg files in both "test" and "test/ci" directories.0
Changes included on feature/coimbra_improve_configuration_search branch of generic_ci repository.

#3 Updated by Gianluca Petrillo about 1 year ago

Has this feature ever been merged into a release?

Two implementation notes about ci:3ded8588b6a97193eca0a113701cacc654917a6c:
  1. without a break at the end of the loop, if there are both configuration files it will read both, which should be avoided
  2. to determine whether the variable is a UPS directory, k.endswith("_DIR") is better than k.find("_DIR") > 0

#4 Updated by Vito Di Benedetto about 1 year ago

Gianluca Petrillo wrote:

Has this feature ever been merged into a release?

Not yet, but there will be a CI release candidate in the next few days that will include this code. If you are interested to test it I can get it merged in the develop branch soon.
The release candidate will be used to cut a "test" UPS product available for testing.

Two implementation notes about ci:3ded8588b6a97193eca0a113701cacc654917a6c:
  1. without a break at the end of the loop, if there are both configuration files it will read both, which should be avoided

we decided to take out the break because we noticed that there will be only one <ExpCode>_DIR set at any time that will point to the local product area or to the build area, so it will never happen to have both configuration files used at the same time.

  1. to determine whether the variable is a UPS directory, k.endswith("_DIR") is better than k.find("_DIR") > 0

This is a good point! We will use your suggestion. Thanks!

#5 Updated by Gianluca Petrillo about 1 year ago

I will test the release candidate when it's available.

Vito Di Benedetto wrote:

Two implementation notes about ci:3ded8588b6a97193eca0a113701cacc654917a6c:
  1. without a break at the end of the loop, if there are both configuration files it will read both, which should be avoided

we decided to take out the break because we noticed that there will be only one <ExpCode>_DIR set at any time that will point to the local product area or to the build area, so it will never happen to have both configuration files used at the same time.

My concern, and it might be just a case of overthinking, is if there are two configuration files in a repository: imagine $MYPRODUCT_DIR pointing to a GIT source repository, and both ${MYPRODUCT_DIR}/ci_tests.cfg and ${MYPRODUCT_DIR}/test/ci_tests.cfg present. That is very likely a mistake, of somebody copying the configuration file in the wrong directory and then committing it into GIT. Again, it's likely just overthinking.

#6 Updated by Vito Di Benedetto about 1 year ago

  • Status changed from Resolved to Closed

We are using a counter to make sure that only 1 ci_tests.cfg is reachable in the environment. If more than 1 ci_test.cfg is found, the test_runner script will end with an exception providing an informative message.
If the user really needs to use more than 1 ci_tests.cfg, this can be achieved through the -c option.

#7 Updated by Vito Di Benedetto about 1 year ago

  • Target version set to v1_6_0


Also available in: Atom PDF