PR: Use Dynamic Branch Ref in GitLab Pipeline Trigger

Summary

The trigger-gitlab-pipelines.yml GitHub Actions workflow was hardcoding ref=develop when posting to the GitLab pipeline trigger API. This prevented the workflow from running CI against branches other than develop — even when a user explicitly selected a different branch (e.g., dev/gfs.v17) from the "Use workflow from" dropdown in the GitHub Actions dispatch UI.

Problem

When triggering the GitLab pipeline manually via Run workflow, GitHub Actions presents a branch selector. The selected branch determines which branch of the repository the workflow YAML is loaded from. However, the curl call that fires the downstream GitLab pipeline was always sending ref=develop regardless of that selection:

# Before — hardcoded
--form "ref=develop" \

This meant:

• Testing a PR against dev/gfs.v17 (or any non-develop branch) would silently run the GitLab pipeline against develop instead.
• Any branch-specific CI configuration, variables, or test matrices defined on that branch would be bypassed.

Fix

Replace the hardcoded value with ${{ github.ref_name }}, which GitHub Actions automatically resolves to the short branch name selected at dispatch time (e.g., develop, dev/gfs.v17):

# After — dynamic
--form "ref=${{ github.ref_name }}" \

github.ref_name is the branch (or tag) name without the refs/heads/ prefix, which is exactly the format the GitLab pipeline trigger API expects for its ref parameter.

Files Changed

File	Change
.github/workflows/trigger-gitlab-pipelines.yml	ref=develop → ref=${{ github.ref_name }}

Behavior After This Change

Dispatch branch selected	GitLab pipeline ref
develop (default)	develop — no change from previous behavior
dev/gfs.v17	dev/gfs.v17
feature/my-branch	feature/my-branch

Testing

1. Trigger the workflow from develop with a PR number — pipeline targets develop as before.
2. Trigger the workflow from dev/gfs.v17 with a PR number — GitLab pipeline now correctly targets the dev/gfs.v17 branch.

Notes

• This is a non-breaking change for all existing develop-branch workflows; the default branch in the dispatch UI remains develop.
• No secrets, variables, or environment settings were modified.