Summary:
We don't want to forget about those so best to remind it when starting tests
as we do with blacklisted tests.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D131
Summary:
Adding if present:
* LD_PRELOAD
* DISPLAY
* GST_VALIDATE_CONFIG
* GST_VALIDATE_OVERRIDE
+ enhance the add_env_variable method to more easily set envvar from
current value
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D78
Summary:
This allows us to easily run all the scenarios on a particular file doing:
$ gst-validate-launcher validate --validate-check-uri file:///some/media/file.webm
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D36
The GstValidatePipelineGenerator was quite limited in term
of configuration for user who just want to specify pipelines
to run with/without scenario.
Enhance the API so that we can properly configure that.
https://bugzilla.gnome.org/show_bug.cgi?id=743994
With the testsuite format you will get a setup_tests(tests_manager,
options) function called for each TestManager.
The function will have the exact same role as with old config
file but with a clean API and not magic global variables.
This implies that we need default blacklist to be directly set
on the TestManager and not on options.blacklisted_test
The default testsuite implementation should belong to the default
asset repo where we have the corresponding knowledge.
We should style manage a sensible list of known blacklisted tests,
encoding profiles, and generators in GstValidate itself and allow testsuite
actual implementations to easily use them though the register_default_*
methods.
This allow us to be able to remove the ugly execfile() call.
