[CI]Improve workflow and CI

[jokemanfire]

Nowadays, many people can participate in development. I think it is necessary to first connect to CI

• CI for commit check
• CI for unit testing and integration testing
• Rust formatted CI cargo fmt cargo clip
• Rust docs CI
• Examples test CI (maybe)
• coverage test
• security test
• may be use hack to cover

[4t145]

Yes we do need a ci for rustdoc

[jokemanfire]

#50 I think there is quite a lot of work that CI needs to do

[Z9RTM]

I'm interested in this one.

Besides the points already listed, I think it might also be beneficial to consider adding CI for:

• build-workspace
• cross-compile
• coverage
• bench
• security (e.g., using cargo audit)
• deps-update (dependabot)
• hack (e.g., using cargo hack)

[jokemanfire]

I'm interested in this one.我对这个感兴趣。

Besides the points already listed, I think it might also be beneficial to consider adding CI for:除了已列出的几点，我认为还应该考虑添加 CI 来：

• build-workspace
• cross-compile  跨平台编译
• coverage  覆盖率
• bench  基准测试
• security (e.g., using cargo audit)安全（例如，使用 cargo audit）
• deps-update (dependabot)
• hack (e.g., using cargo hack)hack (例如，使用 cargo hack)

Thanks , but there are some CI that should be considered after the first version is released. Just not now
1.cross-compile
2.benchmark
3.deps-update
If you could help with this work, thank you very much.

[Z9RTM]

Got it. I'll take this on. Please assign it to me.

[jokemanfire]

May we need show code coverage rate in readme.

[Z9RTM]

Sounds good. I'll take it into consideration.

[Z9RTM]

May we need show code coverage rate in readme.

Considering the conversation, a simple approach to dynamically display a coverage badge could be achieved by integrating grcov and Codecov. I was wondering if we could look into using Codecov?

Here's an example: https://github.com/codecov/example-rust/blob/main/.github/workflows/rust.yml

[jokemanfire]

Yes, we need to consider using it

[Z9RTM]

@dsp-ant
Hi,
As discussed, we're looking into ways to improve the visibility of the code coverage for the rust-sdk project.

A potential solution is to use Codecov for rust-sdk. This service allows us to upload coverage reports generated (e.g., using grcov) and provides a convenient way to display the coverage as a badge in the rust-sdk README. This badge would update automatically with each build, giving a clear and current overview of our test coverage for rust-sdk.

The benefits of using Codecov for rust-sdk include:

Dynamically updated coverage badge in the rust-sdk README.
A more transparent view of the testing efforts for rust-sdk.
Potential insights into areas of rust-sdk needing more testing.
I was wondering if we could proceed with integrating Codecov into the rust-sdk workflow? This would involve setting up the upload of coverage reports to Codecov (likely through our CI/CD pipeline for rust-sdk) and embedding the generated badge link in the rust-sdk README.

Here's an example of how Codecov is used in another project: https://github.com/codecov/example-rust/blob/main/.github/workflows/rust.yml

Please share your opinions and concerns specifically regarding the integration with the rust-sdk repository.

[ssddOnTop]

Hey, there's a crate (and I was one of the core contributors to there) which helps to generate github CI using rust.

Would you like to give it a try and move all CI code to Rust? I can raise a PR