ci: fix merge queue ruleset payload

[Yicong-Huang]

What changes were proposed in this PR?

This PR is a follow-up to #5036 to keep enabling GitHub merge queue while making the ruleset payload accepted by the GitHub repository rulesets API after ASF Infra reported validation errors for the rules array.

Merge queue support:

• Keep the merge_queue rule in .asf.yaml; this PR does not remove or disable merge queue.
• Keep the ruleset display/reconciliation name as Merge Queue.
• Keep the same merge queue behavior: squash merge, up to 5 entries, ALLGREEN, and a 30-minute check response timeout.

Payload compatibility changes:

• Remove source_type and source from the raw ruleset payload because they are response fields and are not needed in the create request body.
• Add allowed_merge_methods: [squash] to the pull_request rule so the pull request rule explicitly matches the repository merge policy.
• Remove do_not_enforce_on_create from the required_status_checks rule to keep the payload aligned with the asfyaml raw ruleset example.
• Remove integration_id: -1 from required status checks because direct GitHub API validation rejected -1 as an invalid integration id, while omitting the field is accepted.

Validation notes:

• Direct API validation on a personal fork rejected merge_queue, which appears to be because merge queue is only available for organization-owned repositories.
• Retested on the organization-owned public repository Texera/Udon using the Yicong-Huang admin account.
• A minimal disabled merge_queue ruleset was created successfully on Texera/Udon and deleted immediately afterward.
• The full ci: fix merge queue ruleset payload #5050 payload, including the ruleset name Merge Queue, was also created successfully as a disabled ruleset on Texera/Udon and deleted immediately afterward.
• This confirms the updated payload shape supports merge_queue in an org-owned repository context.

Any related issues, documentation, discussions?

Related to #4553 and follow-up to #5036.

How was this PR tested?

Ran local configuration checks:

ruby -e 'require "yaml"; cfg=YAML.load_file(".asf.yaml"); rs=cfg.dig("github", "rulesets").find { |r| r["name"] == "Merge Queue" }; abort "missing ruleset" unless rs; abort "unexpected source fields" if rs.key?("source_type") || rs.key?("source"); pr=rs["rules"].find { |r| r["type"] == "pull_request" }; abort "missing allowed_merge_methods" unless pr.dig("parameters", "allowed_merge_methods") == ["squash"]; status=rs["rules"].find { |r| r["type"] == "required_status_checks" }; abort "unexpected do_not_enforce_on_create" if status["parameters"].key?("do_not_enforce_on_create"); abort "unexpected integration_id" if status["parameters"]["required_status_checks"].any? { |c| c.key?("integration_id") }; puts "ruleset sanity ok"'
git diff --check

Also validated against the GitHub repository rulesets API on Texera/Udon:

• Created and deleted a temporary disabled minimal merge_queue ruleset.
• Created and deleted a temporary disabled ruleset using the full ci: fix merge queue ruleset payload #5050 payload with the name Merge Queue.

No automated runtime tests were added because this PR only changes repository configuration.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: OpenAI Codex (GPT-5)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 42.81%. Comparing base (777db47) to head (2812575).

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #5050   +/-   ##
=========================================
  Coverage     42.80%   42.81%           
- Complexity     2205     2206    +1     
=========================================
  Files          1045     1045           
  Lines         40119    40119           
  Branches       4239     4239           
=========================================
+ Hits          17172    17176    +4     
+ Misses        21879    21877    -2     
+ Partials       1068     1066    -2     

Flag	Coverage Δ
access-control-service	39.53% <ø> (ø)
agent-service	33.72% <ø> (ø)
amber	43.69% <ø> (+0.02%)	⬆️
computing-unit-managing-service	0.00% <ø> (ø)
config-service	0.00% <ø> (ø)
file-service	32.18% <ø> (ø)
frontend	33.93% <ø> (ø)
python	88.92% <ø> (ø)
workflow-compiling-service	47.72% <ø> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Yicong-Huang]

Additional investigation on the remaining /rules/2 error:

• This PR keeps the merge_queue rule; it only fixes the surrounding ruleset payload issues.
• I validated through the GitHub API on the fork that the non-merge-queue portion of the payload can create a temporary disabled ruleset once integration_id: -1, do_not_enforce_on_create, and response-only source_type/source are removed.
• I then tested a minimal GraphQL CreateRepositoryRulesetInput containing only a MERGE_QUEUE rule. GitHub still returned Invalid rules: 'Merge queue'.\n- Classic branch protection GraphQL inputs do not expose a requiresMergeQueue field, so rulesets appear to be the only API-visible path.\n\nThis means ci: fix merge queue ruleset payload #5050 should address the /rules/3 and /rules/5 schema errors, but if ASF Infra still sees /rules/2 for merge_queue, that likely requires Infra/GitHub-side support for creating merge queue rules rather than another Texera YAML shape change.

[Yicong-Huang]

Follow-up validation update:

I retested the ruleset API on Texera/Udon, which is an organization-owned public repository where the Yicong-Huang account has admin permission. This is a better match for apache/texera than the earlier personal fork test.

Results:

• A minimal disabled merge_queue ruleset was created successfully via POST /repos/texera/udon/rulesets and deleted immediately afterward.
• A disabled ruleset using the full ci: fix merge queue ruleset payload #5050 payload was also created successfully and deleted immediately afterward.
• No temporary test rulesets remain on Texera/Udon.

Conclusion: the updated #5050 payload supports merge_queue when applied to an organization-owned repository. The earlier Invalid rule 'merge_queue' result was from a personal fork context and is not representative of apache/texera.