The issue you mention should be resolved now with the Pydantic changes.
Do we still have reason to make this change? I guess we could make the
test suites in the config file optional, in which case you can just add
a default to the field and remove the constraint.
On Fri, Jul 5, 2024 at 1:20 PM Nicholas Pratte wrote:
> There is some odd functionality/behavior in how the --test-suite
> parameters interacts in conjunction with the 'test_suites' attribute in
> the config file. If a user leaves an empty list underneath
> 'test_suites,' or if they negate the at
On 5. 7. 2024 19:13, Nicholas Pratte wrote:
There is some odd functionality/behavior in how the --test-suite
parameters interacts in conjunction with the 'test_suites' attribute in
the config file. If a user leaves an empty list underneath
'test_suites,' or if they negate the attribute entirel
I think it makes sense to allow users to not specify any test suites
in the config file if they specify them through other means, so I like
this change.
On Fri, Jul 5, 2024 at 1:20 PM Nicholas Pratte wrote:
>
> There is some odd functionality/behavior in how the --test-suite
> parameters interact
There is some odd functionality/behavior in how the --test-suite
parameters interacts in conjunction with the 'test_suites' attribute in
the config file. If a user leaves an empty list underneath
'test_suites,' or if they negate the attribute entirely, even if said
user adds test suites via the --t
There is some odd functionality/behavior in how the --test-suite
parameters interacts in conjunction with the 'test_suites' attribute in
the config file. If a user leaves an empty list underneath
'test_suites,' or if they negate the attribute entirely, even if said
user adds test suites via the --t
6 matches
Mail list logo
