ci: Remove the gitlab pipeline runs on pre-merge and post-merge workflows

[pvijayakrish]

Overview:

Remove the GitLab pipeline runs from the pre-merge and post-merge developer workflows. This update will also automate RC pipeline execution whenever changes are pushed to the release branch or when a new release branch is created.

Summary by CodeRabbit

• Chores
  • Streamlined internal CI/CD release workflow configuration to improve process efficiency and ensure releases are properly gated to designated release branches.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The GitHub Actions trigger-ci workflow is modified to restrict execution to release branches matching a specific naming pattern, removes multiple preparatory steps including repository checkout and source detection, and simplifies the pipeline script by eliminating extensive environment variable generation and replacing it with minimal release-specific variables.

Changes

Cohort / File(s)	Change summary
GitHub Actions Workflow Refactor \.github/workflows/trigger_ci.yml``	Added guard condition to restrict trigger-ci job to refs matching release/ prefix with dot; removed checkout, paths-filter, and Validation Workflow detection steps; simplified Trigger Pipeline script by removing BUILD_ARCHS, FRAMEWORKS, and nine other conditional environment variables; reduced variable set to NIGHTLY_RUN and RELEASE_BUILD for release builds

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Verify the guard condition logic (release/ prefix + dot requirement) aligns with intended release branch strategy
• Confirm that removed environment variables (BUILD_ARCHS, FRAMEWORKS, ENABLE_BUILD, etc.) are no longer needed for release builds
• Validate that the simplified two-variable approach (NIGHTLY_RUN, RELEASE_BUILD) is sufficient for downstream pipeline execution
• Ensure no critical CI/CD behavior is lost by removing the preparatory steps

Poem

🐰 A workflow so tangled, now neat and precise,
Guard rails in place, workflow runs nice,
Fewer variables to juggle and weigh,
Release builds simpler, hip-hip-hooray! 🎉

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is largely incomplete. It includes only the Overview section, missing the required Details, Where should the reviewer start, and Related Issues sections from the template.	Add the missing sections: Details (explain what was removed and what was added), Where should the reviewer start (point to .github/workflows/trigger_ci.yml), and Related Issues (reference the GitHub issue if applicable).

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: removing GitLab pipeline runs from CI workflows and automating RC pipeline execution.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b7667c4 and 36170c1.

📒 Files selected for processing (1)

• .github/workflows/trigger_ci.yml (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: rmccorm4
Repo: ai-dynamo/dynamo PR: 2775
File: .github/workflows/pre-merge-rust.yml:24-30
Timestamp: 2025-08-29T00:22:31.652Z
Learning: GitHub Actions path filters support both `**.rs` and `**/*.rs` patterns according to minimatch specification. The official GitHub documentation uses `**.js` as an example pattern, and many repositories use `**.rs` successfully for Rust files. Both patterns work, but `**.rs` is documented and widely adopted.

🪛 actionlint (1.7.8)

.github/workflows/trigger_ci.yml

50-50: "github.event.pull_request.head.ref" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks for more details

(expression)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: operator (amd64)
• GitHub Check: Build and Test - dynamo

🔇 Additional comments (2)

.github/workflows/trigger_ci.yml (2)

43-43: Guard condition appropriately restricts execution to release branches.

The guard correctly restricts the job to release branches matching the X.Y.Z naming pattern, aligning with the PR objective to automate RC pipeline execution.

---

54-56: Simplified variable set is appropriate for release-focused workflow.

The reduction to only NIGHTLY_RUN and RELEASE_BUILD aligns with the goal of automating RC pipeline execution with minimal configuration.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[alec-flowers]

I don't think we want to run a full nightly run which includes benchmarking on every cherry-pick. I think the better flow would be the release pick can choose when / if they want to run gitlab-ci and can just manually run it.

[oandreeva-nv]

need to understand the consequences for kvbm tests