ci: use continuous target-branch check for master

[crisryantan]

Background

The Check PR for semantic target branch check fails on every pull request into master, including ones that were merged (#1274, #1254, and currently #1329).

The repo calls the gitflow variant of the shared check:

uses: mParticle/mparticle-workflows/.github/workflows/pr-branch-target-gitflow.yml@stable

That workflow only accepts main, build/ and chore/dependabot branches, and takes no inputs, so master can never satisfy it:

master
Pull request target branch is not valid.
##[error]Process completed with exit code 1.

This repo's default branch is master and it releases from master, so the gitflow variant is simply the wrong one.

What Has Changed

Switch to the continuous (trunk-based) variant that mParticle already publishes, which accepts master in addition to main, build/ and chore/dependabot:

uses: mParticle/mparticle-workflows/.github/workflows/pr-branch-target-continuous.yml@stable

No other job is touched. Note the displayed check name changes from Confirm that target branch for PR is main or build/ to Confirm that target branch for PR is main or master, so any branch-protection rule pinned to the old name would need updating — though since the old check has never passed on master, it cannot currently be a required check.

Test plan

• This PR targets master, so the check on this PR is itself the test: it should now pass
• Confirm the other three reusable-workflow jobs still run (branch name, title, security lint)

Screenshots/Video

• N/A

[cursor]

PR Summary

Low Risk
CI-only workflow wiring with no application, auth, or data-path changes; risk is limited to which shared workflow runs on pull requests.

Overview
Fixes the Check PR for semantic target branch job that was failing on every PR into master because the shared gitflow workflow only allows main, build/, and Dependabot branches.

The reusable workflow job is renamed to pr-branch-target-continuous and now calls pr-branch-target-continuous.yml@stable, which also accepts master for trunk-based releases. Comments in the workflow explain why gitflow is wrong for this repo. Other reusable jobs (branch name, title, security lint) are unchanged.

The check’s displayed name may change (e.g. wording around main vs master); branch protection pinned to the old check name would need updating if it were ever required—which it effectively wasn’t while the check always failed on master.

^{Reviewed by Cursor Bugbot for commit 321e42d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE