Integrate ge.apache.org in the project to prepare for possible performance testing

[linghengqian]

Feature Request

For English only, other languages will not accept.

Please pay attention on issues you submitted, because we maybe need more details.
If no response anymore and we cannot make decision by current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Is your feature request related to a problem?

• See Provide built-in GraalVM Reachability Metadata and introduce a separate nativeTest in CI #2258 (comment) .

@zjx990:
When conducting this kind of automated testing, can we introduce a scenario? Specifically, consider a client or, more accurately, a server that actually executes jobs, reaching its limits.
For example: This instance is an execution node for 900 jobs, which is the actual server. These 900 jobs are scheduled every second. When would this server reach its capacity limit?
My thought: My idea is to focus on its CPU information, since job scheduling is periodic, and thus the CPU usage will also fluctuate periodically. I'll ignore the memory used by the jobs for now. If the CPU peak reaches 70%, then I would consider the limit of this instance to be 900 jobs.

Describe the feature you would like.

• Integrate ge.apache.org in the project to prepare for possible performance testing. Refer to https://infra.apache.org/blog/gradle-has-landed-at-the-asf.html .
• It is not intuitive to perform performance testing on ShardingSphere ElasticJob in CI, which is limited by the fact that Github Actions only provides logs and does not provide much CI data visualization. Using https://ge.apache.org/ to improve the observability of CI may be a good way forward. This should help compare performance changes before and after the project changes.

[linghengqian]

• ge.apache.org is currently using Develocity 2024.1.7, which looks more likely to be unusable than I thought.
•