Feature #18270
Have test_runner find the test configuration file from the source directory
100%
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...
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:- without a
breakat the end of the loop, if there are both configuration files it will read both, which should be avoided - to determine whether the variable is a UPS directory,
k.endswith("_DIR")is better thank.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:
- without a
breakat 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.
- to determine whether the variable is a UPS directory,
k.endswith("_DIR")is better thank.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:
- without a
breakat the end of the loop, if there are both configuration files it will read both, which should be avoidedwe decided to take out the
breakbecause 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