Py/rc testing #2314
Py/rc testing #2314
Conversation
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
| ) | ||
|
|
||
|
|
||
| def start_servers(cluster_mode: bool, shard_count: int, replica_count: int) -> str: |
There was a problem hiding this comment.
Can you re-use start/stop/parse from IT? No need to re-invent the wheel.
There was a problem hiding this comment.
Python is very harsh in this regard, i need the envs to be aware of each other.
If i want to reuse i need to take those functions out to the root folder, create a hack, or call it through cli.
Since it's not really something we use, it's just a fofo test, I'm not sure it's worth it.
Especially if it will affect the efficiency of the IT development because it is extra dependent.
I'm open to hearing if you think differently or you know it's easy to do so.
But importing the base on the path doesn't work.
| output = start_servers(False, 1, 1) | ||
| servers, folder = parse_cluster_script_start_output(output) | ||
| standalone_client = await create_standalone_client(servers) | ||
| await run_commands(standalone_client) |
There was a problem hiding this comment.
Run all IT instead
There was a problem hiding this comment.
We already had this discussion with Bar on the node rc tests.
That's not what those tests should do.
We have IT tests for a reason, and we have rc tests for another, the goal is just a slight check that nothing weird happened, mainly the compilation and packing.
Not to test all functionality.
There was a problem hiding this comment.
We can't find missing exports with these tests. We found missing exports for node client just because I ran all IT on an RC (#2307).
For basic checks you can run benchmark - and again without re-inventing a wheel.
There was a problem hiding this comment.
If we want to run IT against the packed packages we should do it regularly using the npm pack for example and use it as "artifact".
Testing it during release doesn't make sense.
There was a problem hiding this comment.
I understand that it might be needed, but not during release, not against all host types, and do it regularly locally using packing.
The "not inventing the wheel" in the case of using the benchmarks is really much more pain than gain.
You take three different components of the repo with three different use cases and try to jingle between them when python anyway doesn't like stuff that is not in its environment.
I think its an over engineering.
Signed-off-by: Yury-Fridlyand <[email protected]>
Signed-off-by: Yury-Fridlyand <[email protected]>
Signed-off-by: Adar Ovadia <[email protected]>
Signed-off-by: Adar Ovadia <[email protected]>
Signed-off-by: avifenesh <[email protected]>
Signed-off-by: avifenesh <[email protected]>
Signed-off-by: avifenesh <[email protected]>
Signed-off-by: avifenesh <[email protected]>
Signed-off-by: avifenesh <[email protected]>
avifenesh
force-pushed
the
PY/RC-testing
branch
from
1a3eac8
to
e3687b1
Compare
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
avifenesh
temporarily deployed
to
AWS_ACTIONS
GitHub Actions
Inactive
| import { GlideClient, GlideClusterClient } from "@valkey/valkey-glide"; | ||
| import { getServerVersion } from "../../../node/tests/TestUtilities.js"; |
|
Could you please add a description for this PR? How was it done in the previous release? |
No description provided.