rocketmq icon indicating copy to clipboard operation
rocketmq copied to clipboard

[Enhancement] Removing the Bazel workflow

Open RongtongJin opened this issue 6 months ago • 2 comments

Before Creating the Enhancement Request

  • [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Previously, we introduced the Bazel workflow in our community, which can quickly provide test results, but it also introduced some issues:

  • The maintenance cost is relatively high. This includes timely updates to configuration files when new packages are introduced. The workflow often fails due to configuration issues, which can be confusing even when there are no actual problems.

  • Although it can quickly provide test results, multiple workflows run simultaneously, and due to the bucket effect (wooden bucket principle), the final test results still require a long waiting time. Moreover, the test cases in other workflows can cover those in the Bazel workflow.

Therefore, I would like to propose removing this workflow. If you have any suggestions, please feel free to reply below.

Motivation

Removing the Bazel workflow

Describe the Solution You'd Like

Removing the Bazel workflow

Describe Alternatives You've Considered

No

Additional Context

No response

RongtongJin avatar Jun 05 '25 09:06 RongtongJin

Can be deleted, this workflow is often unstable.

yx9o avatar Jun 06 '25 04:06 yx9o

Please assign it to me,I would like to work on this.

OmCheeLin avatar Jun 08 '25 06:06 OmCheeLin

Please assign it to me,I would like to work on this.

done

RongtongJin avatar Jun 20 '25 03:06 RongtongJin

Can be deleted, this workflow is often unstable.

You guys get things totally wrong. It is not the workflow not stable, it's the unit tests that are flaky.

lizhanhui avatar Jun 23 '25 10:06 lizhanhui

“ The maintenance cost is relatively high. This includes timely updates to configuration files when new packages are introduced. The workflow often fails due to configuration issues, which can be confusing even when there are no actual problems.”

Given the frequency of adding new dependency, this reason does not hold.

The workflow offers resource tight scenarios, exposing unstable, flaky test cases and potential bugs... often not found in the hours long slow workflow.

lizhanhui avatar Jun 23 '25 10:06 lizhanhui

Can be deleted, this workflow is often unstable.

You guys get things totally wrong. It is not the workflow not stable, it's the unit tests that are flaky.

I had a PR to solve this problem. I found that there was a difference between jdk8 and jdk11. jdk8 can pass, but jdk11 cannot. In addition, I noticed that there was an issue to support jdk11. Is this still going on? I want to participate?

yx9o avatar Jun 26 '25 03:06 yx9o