Skip to content
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

Reduce CI test time by optimizing task execution #789

Open
hackerwins opened this issue Feb 9, 2024 · 1 comment
Open

Reduce CI test time by optimizing task execution #789

hackerwins opened this issue Feb 9, 2024 · 1 comment
Labels
enhancement 🌟 New feature or request good first issue 🐤 Good for newcomers

Comments

@hackerwins
Copy link
Member

Description:

Currently, when a PR is opened, the CI process runs various tasks including Build and Integration Test, Benchmark, Sharding Test, Releasing Charts, and Publishing Docker Images.

  • Build and Integration Test: 8 mins
  • Benchmark: 5 mins
  • Sharding Test: 3 mins
  • Release Charts: 10 secs
  • Publish Docker Images: 7 mins

The integration Test takes to complete these tasks is 8 minutes.

To ensure that the testing process finishes within 10 minutes, it is necessary to optimize the tasks. Specifically, we should consider the following changes:

  • Rename "Sharding Test" to "Complex Test" to better reflect its purpose.
  • Move the "Tree Concurrency Test" from the Integration Test to the Complex Test.

These changes will help reduce the total test time and ensure that the testing process is completed within the required 10 minutes.

Why:

Currently, the integration test with the Tree Concurrency Test takes up most of the 8-minute test time, causing delays in the CI process. By optimizing the task execution and reducing the test time, we can improve the efficiency of our CI pipeline and ensure timely feedback on pull requests.

@hackerwins hackerwins added enhancement 🌟 New feature or request good first issue 🐤 Good for newcomers labels Feb 9, 2024
highcloud100 added a commit that referenced this issue Feb 12, 2024
1. Now snapshot save latest vector clock not SVM.
2. Clients build their own SVM using the latest VectorClock in snapshots.
- So client's SVM is not latest state, it doesn't know peer's vector clock. It need more check
- This is due to the overhead of storing and transferring SVMs. #789
@krapie
Copy link
Member

krapie commented Mar 5, 2024

I really want this to be optimized. Integration test alone takes almost 4 mins to execute in my local machine(Mac M1 Pro).
Feeling stuck every time I run tests :(

Screenshot 2024-03-05 at 7 15 19 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 🌟 New feature or request good first issue 🐤 Good for newcomers
Projects
Status: Todo
Development

No branches or pull requests

2 participants