Project: treatment-plan · Branch: FHIR-2144-action-factories-refactor · Mode: plan · Model: claude-sonnet-4-6 Stats: 3 user messages, 6 tool calls, tools used: Agent, Read, Grep, Bash. Conversation Turn 1 — User given the current branch was already merged, right after a PR is automatically created to push the new version to the registry: https://github.com/doctolib/treatment-plan/pull/2779. Given the documentation for the release using release-please is https://github.com/googleapis/release-please#release-please. What is missing for this PR to trigger the merge automatically and push the changes to the registry? Turn 1 — Assistant Tools used: - Agent (inputs: description, subagent_type, prompt) Tool results: → result (ok): Perfect! Let me compile all the findings: Release-Please Configuration Summary I've explored the treatment-plan repository and found comprehensive release-please configuration. Here are all the relevant files: 1. release-please-config.json Location: /Users/USER/workspace/doctolib/treatment-plan/release-please-config.json { "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", "plugins": ["node-workspace", "sentence-case"], …(truncated, 7661 more chars) Let me read the key workflow files to give you a precise answer. Tools used: - Read: /Users/USER/workspace/doctolib/treatment-plan/.github/workflows/releaseplease.yml Tool results: → result (ok): 1 name: release-please 2 3 on: 4 workflow_dispatch: 5 push: 6 branches: 7 - main 8 9 permissions: 10 contents: write 11 pull-requests: write 12 id-token: write 13 14 env: 15 SLACK_CHANNEL_TPF_TECH: tpf-tech 16 17 jobs: 18 release-please: 19 runs-on: prod-linux-xs 20 21 steps: 22 - name: Checkout code 23 uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5 24 25 - name: Load Secrets 26 uses: doctolib/actions/load-se …(truncated, 3014 more chars) Tools used: - Read: /Users/USER/workspace/doctolib/treatment-plan/.github/workflows/pr_automation.yml Tool results: → result (ok): 1 name: PR Automation 2 3 on: 4 pull_request_target: 5 types: [labeled] 6 7 permissions: 8 contents: read 9 id-token: write 10 11 jobs: 12 auto-merge: 13 runs-on: prod-linux-xs 14 timeout-minutes: 5 15 if: ${{ github.event.label.name == 'auto-merge' }} 16 steps: 17 - name: Load Secrets 18 uses: doctolib/actions/load-secrets@main 19 with: 20 prefix_secrets: true 21 sparse-checkout-first: true 22 - name: Auto Merge 23 …(truncated, 199 more chars) Now I have the full picture. Let me check if there are other workflows that handle the auto-approve label: Tools used: - Grep: auto-approve in /Users/USER/workspace/doctolib/treatment-plan/.github/workflows Tool results: → result (ok): No matches found Found it. Here's the answer: --- The setup is almost complete but has one missing piece: there is no workflow that handles the auto-approve label. What exists | Label | Config | Workflow handler | |---|---|---| | auto-merge | extra-label in release-please-config.json | pr_automation.yml → doctolib/actions/auto-merge ✅ | | auto-approve | extra-label in release-please-config.json | Nothing ❌ | What the flow looks like today 1. Your branch is merged to main 2. releaseplease.yml triggers → googleapis/release-please-action creates PR #2779 with both labels auto-approve,auto-merge 3. pr_automation.yml fires on the auto-merge label → calls doctolib/actions/auto-merge → enables GitHub's auto-merge on the PR 4. Auto-merge is now waiting for branch protection requirements (required review approval) to be satisfied 5. The auto-approve label fires... but there is no handler for it → PR never gets approved → auto-merge is stuck indefinitely What's missing A job in pr_automation.yml that handles the auto-approve label and programmatically approves the PR using a GitHub App token. The standard pattern: auto-approve: runs-on: prod-linux-xs timeout-minutes: 5 if: ${{ github.event.label.name == 'auto-approve' }} steps: - name: Load Secrets uses: doctolib/actions/load-secrets@main with: prefix_secrets: true sparse-checkout-first: true - name: Auto Approve run: gh pr review --approve "${{ github.event.pull_request.html_url }}" env: GH_TOKEN: ${{ env.VAULT_SECRET_GITHUB_APP_TOKEN }} # needs a from the PR author The approval token cannot be the same identity that created the PR (GitHub blocks self-approval). That's why a dedicated GitHub App token is used — which is already available via the load-secrets step used in the rest of the CI. ★ Insight ───────────────────────────────────── - release-please's extra-label is purely declarative — it stamps labels on the PR but has zero behavior on its own. You need a separate workflow responding to each label event. - GitHub's auto-merge feature enables merging when conditions are met, but enabling it and satisfying those conditions are two separate actions. auto-merge enables the gate; auto-approve satisfies the required-review condition that the gate is waiting on. - The two labels must come from different GitHub identities: the release-please bot creates the PR and adds labels, a separate app it. Using the same token would fail silently (GitHub rejects self-reviews). ───────────────────────────────────────────────── Turn 2 — User Is there something I can re-run to trigger this auto-approve? Turn 2 — Assistant No — since there's no auto-approve workflow handler, no re-run will fix it. Re-applying the label would just re-trigger doctolib/actions/auto-merge, which is likely already enabled on the PR. The fastest path right now: manually approve PR #2779 on GitHub. Auto-merge is almost certainly already enabled (from when the auto-merge label fired), so once you add a manual approval and CI passes, it will merge and publish automatically. gh pr review 2779 --approve --repo doctolib/treatment-plan Or approve it via the GitHub UI. After that, no further action needed — auto-merge will take over. The missing auto-approve job in pr_automation.yml is the permanent fix to prevent this from needing manual intervention on future release PRs. Turn 3 — User Considering the manual approve is not possible. How should I handle? Is there any action I can re-run? Turn 3 — Assistant Given that, the most practical option depends on what doctolib/actions/auto-merge actually does internally. Let me check if it might already handle approval: Tools used: - Bash: gh workflow list --repo doctolib/treatment-plan 2>/dev/null | head -20 Tools used: - Bash: gh pr view 2779 --repo doctolib/treatment-plan --json state,labels,statusCheckRollup,autoMergeRequest,reviewDecision 2>/dev/null Tool results: → result (ok): JS tests active 137837163 Dependency Submission active 138512613 Dependabot Updates active 138512626 [Pact tests] Consumer contract tests active 147856315 [Pact tests] Verify contract active 147856316 PR Automation active 154655228 Frontend Compliance active 176079324 E2E tests active 176223322 Java tests active 176225981 Frontend Metrics active 176225982 Claude PR Review active 176545532 Deployment Notifier active 177753393 Frontend linting active 178486918 Static tests active 179068511 PR ESLi …(truncated, 279 more chars) Tool results: → result (ok): {"autoMergeRequest":{"authorEmail":null,"commitBody":null,"commitHeadline":null,"mergeMethod":"MERGE","enabledAt":"2026-04-07T09:18:29Z","enabledBy":{"is_bot":true,"login":"app/doctolib-ci-app-2"}},"labels":[{"id":"LA_kwDONihgh88AAAAB2LV5qA","name":"auto-approve","description":"","color":"EDEDED"},{"id":"LA_kwDONihgh88AAAAB2LV6Yw","name":"auto_risk_level:medium","description":"C5 automatic risk assessment done by GHA","color":"C5DEF5"},{"id":"LA_kwDONihgh88AAAAB2LWAOw","name":"auto-merge","descr …(truncated, 14180 more chars) Now I have the real picture. The PR has two distinct blockers: reviewDecision: "REVIEW_REQUIRED" ← no approval yet detect-frontend-breaking-changes ← FAILURE (one run) Auto-merge is already enabled (done by app/doctolib-ci-app-2 at 09:18), so that's not the issue. Here's what's actually blocking it: Blocker 1 — Failing check (re-runnable) The Frontend Breaking Changes Detection check failed. However, the skip-breaking-changes label was already added to the PR (by the "Skip Frontend Breaking Changes on release PR" workflow). Re-running it now should pass/skip because the label is in place. Find the failed run ID and re-run it gh run list --repo doctolib/treatment-plan --workflow "Frontend Breaking Changes Detection" --limit 5 gh run rerun --repo doctolib/treatment-plan --failed Blocker 2 — Missing approval (not re-runnable, needs a fix) reviewDecision: REVIEW_REQUIRED — this is the hard blocker. The auto-approve label is on the PR but nothing handles it, as diagnosed earlier. The only fix here is adding the missing job to pr_automation.yml and then re-applying the auto-approve label to PR #2779. Summary | Blocker | Can re-run? | Fix | |---|---|---| | detect-frontend-breaking-changes FAILED | Yes — re-run the workflow | gh run rerun --failed | | reviewDecision: REVIEW_REQUIRED | No | Add auto-approve job to pr_automation.yml, then remove+re-add the auto-approve label on PR #2779 | Fixing only the CI check won't be enough — the review requirement will still hold. Both need to be resolved.