-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sometimes server artifacts are placed in a different folder from the one that was reported #304
Labels
bug
Something isn't working
Comments
ochaplashkin
pushed a commit
to ochaplashkin/luatest
that referenced
this issue
Sep 26, 2023
Previously, the "principle of single responsibility" was not observed in the `update_status()` - the method should do one thing. The part related to output has been moved to a higher level so that the principle is respected. This will allow you to work with internal test content (e.g servers) before output to stdout. Part of tarantool#304
ochaplashkin
pushed a commit
to ochaplashkin/luatest
that referenced
this issue
Sep 26, 2023
Due to the specifics of working with the test and the added connection between `test <-> server` as well as because artifacts will be saved with a connection problem [1], the `Server:save_artifacts()` method were called more than once. In case of any problems we could overwrite already saved artifacts. Added a flag that will ensure that the saving will be executed only once. There was also a problem when copying artifacts was not performed but the path to the artifacts was formed as a directory with artifacts (as if it exists): artifacts: server -> /tmp/t/artifacts/server-XXX And if we try to look at these artifacts, nothing will work: $ ls -la /tmp/t/artifacts/server-XXX ls: cannot access '/tmp/t/artifacts/server-XXX': No such file or directory To show explicitly that the saving failed with an error, the string will now be written to the artifacts: artifacts: server -> Failed to copy artifacts for server (workdir: /tmp/t/artifacts/server-XXX) [1] tarantool/luatest@251b35f Close tarantool#304
ochaplashkin
pushed a commit
to ochaplashkin/luatest
that referenced
this issue
Oct 2, 2023
Due to the specifics of working with the test and the added connection between `test <-> server` as well as because artifacts will be saved with a connection problem [1], the `Server:save_artifacts()` method were called more than once. In case of any problems we could overwrite already saved artifacts. Added a flag that will ensure that the saving will be executed only once. There was also a problem when copying artifacts was not performed but the path to the artifacts was formed as a directory with artifacts (as if it exists): artifacts: server -> /tmp/t/artifacts/server-XXX And if we try to look at these artifacts, nothing will work: $ ls -la /tmp/t/artifacts/server-XXX ls: cannot access '/tmp/t/artifacts/server-XXX': No such file or directory To show explicitly that the saving failed with an error, the string will now be written to the artifacts: artifacts: server -> Failed to copy artifacts for server (workdir: /tmp/t/artifacts/server-XXX) [1] tarantool/luatest@251b35f Close tarantool#304
ochaplashkin
pushed a commit
to ochaplashkin/luatest
that referenced
this issue
Oct 2, 2023
Due to the specifics of working with the test and the added connection between `test <-> server` as well as because artifacts will be saved with a connection problem [1], the `Server:save_artifacts()` method were called more than once. In case of any problems we could overwrite already saved artifacts. Added a flag that will ensure that the saving will be executed only once. There was also a problem when copying artifacts was not performed but the path to the artifacts was formed as a directory with artifacts (as if it exists): artifacts: server -> /tmp/t/artifacts/server-XXX And if we try to look at these artifacts, nothing will work: $ ls -la /tmp/t/artifacts/server-XXX ls: cannot access '/tmp/t/artifacts/server-XXX': No such file or directory To show explicitly that the saving failed with an error, the string will now be written to the artifacts: artifacts: server -> Failed to copy artifacts for server (workdir: /tmp/t/artifacts/server-XXX) [1] tarantool/luatest@251b35f Close tarantool#304
ochaplashkin
pushed a commit
to ochaplashkin/luatest
that referenced
this issue
Oct 6, 2023
Due to the specifics of working with the test and the added connection between `test <-> server` as well as because artifacts will be saved with a connection problem [1], the `Server:save_artifacts()` method were called more than once. In case of any problems we could overwrite already saved artifacts. Added a flag that will ensure that the saving will be executed only once. There was also a problem when copying artifacts was not performed but the path to the artifacts was formed as a directory with artifacts (as if it exists): artifacts: server -> /tmp/t/artifacts/server-XXX And if we try to look at these artifacts, nothing will work: $ ls -la /tmp/t/artifacts/server-XXX ls: cannot access '/tmp/t/artifacts/server-XXX': No such file or directory To show explicitly that the saving failed with an error, the string will now be written to the artifacts: artifacts: server -> Failed to copy artifacts for server (workdir: /tmp/t/artifacts/server-XXX) [1] tarantool/luatest@251b35f Close tarantool#304
ochaplashkin
pushed a commit
to ochaplashkin/luatest
that referenced
this issue
Oct 6, 2023
Since commit [1] the `Server:save_artifacts()` function was called more than once. Due to this fact we could overwrite already saved artifacts. Added a flag that will ensure that the saving will be executed only once. There was also a problem when copying artifacts was not performed but the path to the artifacts was formed as a directory with artifacts: artifacts: server -> /tmp/t/artifacts/server-XXX And if we tried to look at these artifacts, we could see this: $ ls -la /tmp/t/artifacts/server-XXX ls: cannot access '/tmp/t/artifacts/server-XXX': No such file or directory To show explicitly that the saving failed with an error, the following string will now be written to the artifacts: artifacts: server -> Failed to copy artifacts for server (alias: server-XXX workdir: /tmp/t/artifacts/server-XXX) [1] tarantool/luatest@251b35f Part of tarantool#304
ylobankov
pushed a commit
that referenced
this issue
Oct 6, 2023
Since commit [1] the `Server:save_artifacts()` function was called more than once. Due to this fact we could overwrite already saved artifacts. Added a flag that will ensure that the saving will be executed only once. There was also a problem when copying artifacts was not performed but the path to the artifacts was formed as a directory with artifacts: artifacts: server -> /tmp/t/artifacts/server-XXX And if we tried to look at these artifacts, we could see this: $ ls -la /tmp/t/artifacts/server-XXX ls: cannot access '/tmp/t/artifacts/server-XXX': No such file or directory To show explicitly that the saving failed with an error, the following string will now be written to the artifacts: artifacts: server -> Failed to copy artifacts for server (alias: server-XXX workdir: /tmp/t/artifacts/server-XXX) [1] 251b35f Part of #304
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am running tests from replicaiton-luatest suite with test-run on MacOS Ventura 13.3
After one of the unsuccessful test runs I got the following output:
But the specified folder was nonexistent:
At the same time, the specified files were present in another directory artifacts/001_replication-luatest instead of 001_replication-luatest/artifacts:
This happens only sometimes. Sometimes the artifacts happen to be where luatest says they should be.
The text was updated successfully, but these errors were encountered: