chore: remove ci main workflow

[huangjw806]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Because we now have a pull-request pipeline and a merge-queue, we think it is not necessary to run the main pipeline again after the merge. In addition, we also run the main-cron pipeline every day.

After removing the main pipeline, we can save at least 20% of CI costs.

• Migrate unique jobs in main pipeline to main-cron pipeline;
• Migrate release and docker jobs in main pipeline to docker pipeline;
• Remove main pipeline;
• enable docker pipeline Github tag webhook active;

Releated issue: close #12230

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

[kwannoel]

I guess this has added bonus of only having to make sure 2 pipelines are stable rather than monitoring 3 different ones.

The main thing to note is that we lose test coverage on release build for each main commit. Now only 1 main commit at the end of the day will be tested via main-cron.

I think we can merge it, see how it performs. If there's many errors which are only found in main / main-cron, then we should revert, to catch these errors per main commit, OR in merge queue instead of running pull-request workflow, we run main workflow instead.

[huangjw806]

I guess this has added bonus of only having to make sure 2 pipelines are stable rather than monitoring 3 different ones.

In fact, we are not paying attention to every failed main pipeline now. In the future, we only need to strictly pay attention to the failed main-cron pipeline.

[kwannoel]

I guess this has added bonus of only having to make sure 2 pipelines are stable rather than monitoring 3 different ones.

In fact, we are not paying attention to every failed main pipeline now. In the future, we only need to strictly pay attention to the failed main-cron pipeline.

You are right, it is not strictly paid attention to. I think this would be the alternative then, since it would block PRs from merging unless it passes:

OR in merge queue instead of running pull-request workflow, we run main workflow instead.

[codecov]

Codecov Report

Merging #12232 (52ced32) into main (43852dc) will decrease coverage by 0.01%.
Report is 1 commits behind head on main.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #12232      +/-   ##
==========================================
- Coverage   69.73%   69.73%   -0.01%     
==========================================
  Files        1409     1409              
  Lines      235961   235961              
==========================================
- Hits       164553   164552       -1     
- Misses      71408    71409       +1     

Flag	Coverage Δ
rust	69.73% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 3 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more