You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
cnf-config option can take only files with "cnf-testsuite.yml" name, usage of other filenames causes failures or leads to very unexpected behavior.
Describe the solution you'd like
Possibility to use different names for cnf config file. Some solution would be needed for constants and "CNFManager.cnf_config_list" function. Easiest one (but not a nice one) would be allowing user to use their config name, but rename it to "cnf-testsuite.yml" on copy to internal cnfs/* directory.
Describe alternatives you've considered
Leave limitations of config naming as it is now, but give user clear error messages and don't allow him to use any other name for cnf-config parameter. Error should be given at the earliest stages so no actions would be made by the application.
**How will this be tested? aka Acceptance Criteria (optional) **
(optional: unnecessary for things like some version bumps etc.)
Once this issue is addressed how will the fix be verified?
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
cnf-config option can take only files with "cnf-testsuite.yml" name, usage of other filenames causes failures or leads to very unexpected behavior.
Describe the solution you'd like
Possibility to use different names for cnf config file. Some solution would be needed for constants and "CNFManager.cnf_config_list" function. Easiest one (but not a nice one) would be allowing user to use their config name, but rename it to "cnf-testsuite.yml" on copy to internal cnfs/* directory.
Describe alternatives you've considered
Leave limitations of config naming as it is now, but give user clear error messages and don't allow him to use any other name for cnf-config parameter. Error should be given at the earliest stages so no actions would be made by the application.
**How will this be tested? aka Acceptance Criteria (optional) **
(optional: unnecessary for things like some version bumps etc.)
Once this issue is addressed how will the fix be verified?
The text was updated successfully, but these errors were encountered: