Added SLC deployment integration tests #6
Conversation
# Conflicts: # exasol/python_extension_common/deployment/language_container_deployer.py # exasol/python_extension_common/deployment/language_container_deployer_cli.py # pyproject.toml # test/unit/deployment/test_language_container_deployer.py # test/unit/deployment/test_language_container_deployer_cli.py
| """ | ||
| test_name: str = request.node.name | ||
| schema = test_name | ||
| language_alias = f"PYTHON3_TE_{test_name.upper()}" |
There was a problem hiding this comment.
| language_alias = f"PYTHON3_TE_{test_name.upper()}" | |
| language_alias = f"PYTHON3_PEC_{test_name.upper()}" |
There was a problem hiding this comment.
- test_name.upper() might need sanitization should these tests every get parameterized
- maybe extract into function, because you need to build the language_alias in many more tests
There was a problem hiding this comment.
Actually, I don't think we need to do anything fancy here. We always revert the language settings. So just a constant name, like "PYTHON3_PEC", would do. Same for the schema. We only need the schema to run a test udf. We don't need to create many of them.
What concerns me is that we use the same name for the container in the bucketfs in multiple tests. If some test fails to upload the container the test, theoretically, may still pass because the container is there from the previous test. On the other hand, making an uncontrolled number of copies of the container is not a good option either. Ideally, we would delete the container at the end of each test, but I am not sure how to delete an archive from the bucketfs.
There was a problem hiding this comment.
You are right, we reset the language settings, so it shouldn't be an issue to use a constant.
Regarding removing a file from bucketfs, in theory the bucketfs-python has functions for that, but I am not sure, if the API we are using has it. Furthermore, is removing a file from bucketfs a bit delicate, you might need to wait a bit before you can upload the a file under the same name.
There was a problem hiding this comment.
Maybe it is the best to wait for the container removal until we introduce the new bucketfs API, because it for sure supports removal. What do you think?
There was a problem hiding this comment.
Yes, the removal is finicky. I've been experimenting with normal files recently. If you delete a file and try to upload another file with the same name immediately after (next test), it fails. I had to wait like 10-20 seconds. I don't know if we can delete an archive. I haven't tried that. Will it delete both the tar and the unzipped directory? How long will we have to wait after that?
There was a problem hiding this comment.
Yes, IT will removed both. Regarding the time or needs, that is a really good question. Probably, something we need to try and what also can be very different for SaaS.
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
Co-authored-by: Torsten Kilias <[email protected]>
closes #5