feat: migrate go-pr-analysis and frontend-pr-analysis to use changed-paths composite

[bedatty]

Request Type

Refactor / simplification

Affected Workflow (if applicable)

Go (ci, security, release, pr-analysis)
TypeScript (ci, release, frontend-pr-analysis)

Problem / Motivation

The go-pr-analysis.yml and frontend-pr-analysis.yml reusable workflows have inline change detection logic duplicated in a detect-changes job, instead of using the src/config/changed-paths composite action.

Other workflows like build.yml and pr-security-scan.yml already use the composite action. This duplication means bug fixes or improvements to change detection need to be applied in multiple places.

Proposed Solution

Replace the inline detect-changes job in both workflows with a call to LerianStudio/github-actions-changed-paths, passing get_app_name: true.

Before migrating, the composite may need an enhancement to handle the PR diff fallback that the inline logic has:

git fetch origin $BASE_SHA --depth=1 2>/dev/null || true
FILES=$(git diff --name-only $BASE_SHA $HEAD_SHA 2>/dev/null || git diff --name-only origin/${{ github.base_ref }}...HEAD)

The current composite does not have this fallback for shallow clone scenarios.

Alternatives Considered

Keep the inline logic as-is, but this increases maintenance burden and risk of divergence between workflows.

Example Usage

# Inside go-pr-analysis.yml / frontend-pr-analysis.yml
detect-changes:
  name: Detect Changes
  runs-on: ${{ inputs.runner_type }}
  outputs:
    matrix: ${{ steps.changed-paths.outputs.matrix }}
    has_changes: ${{ steps.changed-paths.outputs.has_changes }}
  steps:
    - name: Get changed paths
      id: changed-paths
      uses: LerianStudio/github-actions-changed-paths@main
      with:
        filter_paths: ${{ inputs.filter_paths }}
        path_level: ${{ inputs.path_level }}
        get_app_name: 'true'
        app_name_prefix: ${{ inputs.app_name_prefix }}

Would This Be a Breaking Change?

No — fully backward compatible

Checklist

• I searched existing issues and this is not a duplicate.
• This feature aligns with the repository's goal of providing reusable, organization-wide workflows.

Additional Context

Differences between composite and inline logic:

Feature	Composite (changed-paths)	Inline (go-pr-analysis / frontend-pr-analysis)
app_name_overrides	✅ Supported	❌ Not supported
normalize_to_filter	✅ Supported	❌ Not supported
Tag push detection	✅ Compares previous tags	❌ Only compares commits
PR diff fallback	❌ No fallback for missing base.sha	✅ Fallback to origin/$base_ref...HEAD
get_app_name toggle	✅ Optional	❌ Always outputs name/working_dir

Risks:

1. The composite needs the PR diff fallback added before migration to avoid breaking shallow clone scenarios
2. Callers must pass get_app_name: true otherwise downstream jobs using matrix.app.name will break