chore(ci): GHA cold-cut migration — retire WP/Drone, add GHA caller

[satyamsundaram01]

Automated GHA migration (SRE). Retires legacy Woodpecker/Drone CI; routes through moengage/github-workflows thin-caller. Cache lock fix already on master. Full deploy chain incl manifest-gen enabled.

[moe-hodor]

🚪 Hodor is reviewing this PR... 👀

[moe-hodor]

🔴 Critical — Wrong workflow template: This repo is a Flutter/Dart SDK with no Python code, but you're calling python-ci.yaml which is designed for Python services with /executor, venv builders, CodeDeploy, etc.

Why this is wrong:

• Flutter-SDK has no requirements.txt, setup.py, or Python dependencies
• The repo already has a full Flutter CI workflow in .github/workflows/verify-pull-request.yml (melos, dart format, flutter test, gradle, cocoapods)
• The python-ci.yaml workflow template's inputs (lint, test, venv_build, cd_deploy) are Python-specific abstractions

Impact: While disabling all the Python gates prevents outright breakage, this creates architectural debt — future maintainers will see a Python CI template in a Flutter repo and wonder why.

Fix: Either:

1. Use moengage/github-workflows/actions/secret-check@master directly (lightweight, no Python assumptions), OR
2. Add a comment explaining this is intentionally a thin caller for secret scanning only, with full CI in verify-pull-request.yml

[moe-hodor]

⚠️ Warning — Unused tag trigger: The workflow triggers on tags: ['**'] but with all build/test/deploy gates disabled (enable_lint: 'false', enable_test: 'false', enable_cd_deploy: 'false'), tag pushes will only run secret scanning.

Flutter-SDK releases are handled by .github/workflows/release-plugins.yml (manual workflow that publishes to pub.dev). Tag pushes don't need this workflow.

Fix: Remove the tags: ['**'] trigger unless you plan to integrate with the release process.

[moe-hodor]

💡 Suggestion — Redundant flag for non-Python repo: use_gha_venv_path: 'false' controls the S3 path prefix for Python venv tarballs (python3/gha/venvs/...). Since this repo has no Python code and enable_venv_build defaults to true in python-ci.yaml, venv-builder jobs will be scheduled and then skip due to missing setup.py.

Cleaner approach: If you must use python-ci.yaml, explicitly set enable_venv_build: 'false' in the caller to prevent venv jobs from being scheduled at all (matches the library-repo pattern documented in the python-ci.yaml input descriptions).

[moe-hodor]

ℹ️ Note — Comment explains thin-caller intent: The inline comment says "secret-scan only; no build pipeline in source", which is accurate since verify-pull-request.yml handles the actual Flutter builds/tests. However, the comment doesn't explain why a Python workflow is being used for a Flutter repo.

Suggest adding:

# Thin caller — secret-scan only for branch protection gate.
# Full PR verification (lint, test, build) runs in verify-pull-request.yml.
# Uses python-ci.yaml for consistency with SRE migration tooling; all
# Python-specific gates are disabled.

This prevents future "why is there a Python CI in a Dart repo?" confusion.

[moe-hodor]

🔴 Critical — k8s_support: 'false' correct, but misleading in context: Flutter-SDK doesn't deploy to K8s (it's a client SDK published to pub.dev, not a service). Setting k8s_support: 'false' is correct, but the fact that this flag exists in the caller highlights the architectural mismatch — K8s support is a server-side deployment concern, not relevant to mobile SDKs.

This flag wouldn't exist in a Flutter-native workflow template.

Fix: Use a workflow template that matches the repo's purpose (SDK publish, not service deploy).

[moe-hodor]

🔴 Critical — PR close trigger without merge check: The workflow triggers on pull_request: types: [closed] but doesn't check if: github.event.pull_request.merged == true. This means the secret scan will run on EVERY PR close, including when PRs are closed without merging (abandoned, rejected).

In python-ci.yaml, the closed event is typically used with deployment jobs that gate on merge status. For secret scanning, you only need [opened, synchronize].

Fix: Remove closed from the types array:

pull_request:
  branches: ['**']
  types: [opened, synchronize]

This matches the pattern in verify-pull-request.yml (line 4) which uses types: [opened, reopened, ready_for_review, synchronize].

[moe-hodor]

Review Summary

This PR migrates from Woodpecker CI to GitHub Actions, but there's a critical architectural mismatch: the new workflow calls python-ci.yaml which is designed for Python services, while Flutter-SDK is a Dart/Flutter mobile SDK repository with zero Python code.

Branching & CFR: patch/MOEN-gha-migration — category: patch, impact: Neutral CFR ✅

---

Quality Gates

✅ PR Size: 26 lines — clean and focused
✅ Commits: Follows Conventional Commits
⚠️ Config: Config file added — verify behavior matches old pipeline
✅ Duplication: No copy-paste issues
✅ Tests: N/A (CI config change)

---

Issues Found

🔴 Critical: 3
⚠️ Warning: 1
💡 Suggestion: 1

---

Key Concerns

🔴 Wrong Workflow Template

The PR uses moengage/github-workflows/.github/workflows/python-ci.yaml for a Flutter/Dart repository that has:

• No requirements.txt, setup.py, or pyproject.toml
• No Python code at all
• Existing Flutter-specific CI in .github/workflows/verify-pull-request.yml (melos bootstrap, dart format, flutter analyze, flutter test, flutter build)

The python-ci.yaml workflow is architected for Python services and includes:

• /executor Python lint/test
• py3-venv-builder (Python virtualenv for CodeDeploy)
• Python package builds
• CodeDeploy/K8s deployment gates

While disabling lint/test/deploy via flags prevents those jobs from running, the workflow itself is the wrong abstraction for this repo.

🔴 CI Coverage Regression Risk

The old Woodpecker pipeline (.woodpecker.yml) ran:

1. Secret scanning (TruffleHog)
2. Slack notification on failure

The existing GHA workflow (.github/workflows/verify-pull-request.yml) runs:

1. melos bootstrap + get (dependency install)
2. flutter pub publish --dry-run (publishing checks)
3. dart format + verify (code formatting)
4. melos analyze (static analysis)
5. melos unittest (tests on *interface* packages)
6. flutter build apk + ktlint (Android Kotlin lint)
7. flutter build ipa (iOS builds, both regular and SPM)

The new thin caller runs only:

• Secret scanning

This means the new workflow does NOT replace the full PR verification — it only replaces the secret scan portion of the old Woodpecker pipeline. PR builds, tests, lints, and native compilation are handled by the separate verify-pull-request.yml workflow which already exists.

⚠️ No Tag/Release Pipeline Defined

The old Woodpecker pipeline only ran on branches (no tag-push behavior). The new caller triggers on tags: ['**'] but with all build/deploy gates disabled, tag pushes will only run secret scanning, which is likely not the intended release process.

Flutter-SDK has a separate manual release workflow (.github/workflows/release-plugins.yml) triggered via workflow_dispatch that:

• Merges development → master
• Creates GitHub releases
• Publishes to pub.dev

The tag trigger in the new workflow doesn't integrate with this release process.

---

What's Good

✅ Gradual Migration: Disabling Python-specific gates prevents outright breakage
✅ Secret Scanning: TruffleHog integration preserved
✅ Permissions: Correctly scoped id-token, contents, actions
✅ Backup Preserved: Old .woodpecker.yml renamed to .Jun04-bkp for rollback

---

Regression Risk

Medium — The new workflow won't break existing CI because:

• The full PR verification workflow (verify-pull-request.yml) already exists and will continue to run
• The new thin caller only adds secret scanning on top

However, the architectural mismatch creates confusion:

• Future maintainers will see a Python CI template in a Flutter repo
• Tag pushes will trigger a no-op pipeline
• No clear migration path to a Flutter-native workflow

---

Recommendations

Option 1: Create a Minimal Flutter/SDK Workflow (Recommended)

The github-workflows repo doesn't have a Flutter-specific template yet. For SDK repos that only need secret scanning + branch protections, create a minimal caller:

# .github/workflows/ci.yaml
name: CI
on:
  push:
    branches: ['**']
  pull_request:
    branches: ['**']

jobs:
  secret-check:
    uses: moengage/github-workflows/actions/secret-check@master
    with:
      fail_on_findings: true
    secrets: inherit
    permissions:
      contents: read

This is architecturally cleaner and doesn't carry the Python-service assumptions.

Option 2: Document the Intent

If this is intentional (thin caller just for secret scanning, PR verification stays in verify-pull-request.yml), add a comment in the workflow file:

# Thin caller — secret-scan only for branch protection gate.
# Full PR verification (lint, test, build) runs in verify-pull-request.yml
name: CI

And remove the tags: ['**'] trigger since Flutter-SDK releases via manual workflow.

---

Verdict

REQUEST_CHANGES — The Python workflow template is the wrong abstraction for a Flutter SDK repository. While it won't break existing CI, it creates architectural debt and confusion. Either use a lightweight secret-scan-only action or document the split-brain CI approach (this file for secret scan, verify-pull-request.yml for actual builds/tests).

The migration is well-intentioned and the flags prevent immediate breakage, but the foundation should match the repo's language/purpose.

---

Hodor holds the gate. Wrong workflow template for a Flutter repo. 🔴

[satyamsundaram01]

Skipped - Covered by Wiz (org-wide secret/security scanning already enabled; this repo's Woodpecker/Drone pipeline was secret-scanning only, so a GHA migration adds no coverage).