On 10/24/2016 10:27 AM, Amador Pahim wrote: > Hello, > > I saw a number of requests about setUpClass/tearDownClass. We don't > actually support them in Avocado, as already stated in our docs, but > most of the requests are actually interested in have a temporary > directory that can be the same throughout the job, so every test can > use that directory to share information that is common to all the > tests. > > One way to provide that would be exposing the Job temporary directory, > but providing a supported API where a test can actually write to > another test results can break our promise that tests are independent > from each other. >
Yes, the initial goal of a job temporary directory is to prevent clashes and allow proper cleanup when a job is finished. For those not familiar with the current problems of (global) temporary directories: https://trello.com/c/qgSTIK0Y/859-single-data-dir-get-tmp-dir-per-interpreter-breaks-multiple-jobs > Another way that comes to my mind is to use the pre/post plugin to > handle that. On `pre`, we can create a temporary directory and set an > environment variable with the path for it. On `post` we remove that > directory. Something like: > > ``` > class TestsTmpdir(JobPre, JobPost): > ... > > def pre(self, job): > os.environ['AVOCADO_TESTS_TMPDIR'] = > tempfile.mkdtemp(prefix='avocado_') > > def post(self, job): > if os.environ.get('AVOCADO_TESTS_TMPDIR') is not None: > shutil.rmtree(os.environ.get('AVOCADO_TESTS_TMPDIR')) > ``` > > Thoughts? > I think this can be a valid solution, that promises very little to tests. It doesn't break our assumption of how tests should not depend on each other, and it reinforces that we aim at providing job level orchestration. Although, since we have discussed giving a job its own temporary dir, and we already expose a lot via environment variables to tests: http://avocado-framework.readthedocs.io/en/latest/WritingTests.html#environment-variables-for-simple-tests And also to job pre/post script plugins: http://avocado-framework.readthedocs.io/en/latest/ReferenceGuide.html#script-execution-environment I'm afraid this could bring inconsistencies or clashes in the very near future. What I propose for the immediate terms is to write a contrib/example plugin, that we can either fold into the Job class itself (giving it a real temporary dir, with variables exposed to test processes) or make it a 1st class plugin. How does it sound? -- Cleber Rosa [ Sr Software Engineer - Virtualization Team - Red Hat ] [ Avocado Test Framework - avocado-framework.github.io ]
signature.asc
Description: OpenPGP digital signature
