From cfad718b0ac9c10f60feff06826ef3436ead5331 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 7 Aug 2026 12:46:14 +0000 Subject: [PATCH] Check develop after a merge, not just main MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `develop` became the integration branch when #3 merged into it, but CI's push trigger still named only `main` — so the merge commit itself ran nothing. A pull request is checked before the merge, not after, which leaves the state of the branch people actually build from unverified whenever two green pull requests conflict semantically. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G --- .github/workflows/ci.yml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 7a26435..7fdc7ad 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -1,10 +1,12 @@ name: CI -# Runs on pull requests and on the branch they merge into, so a green tick means the code was -# checked in the state it will actually land in. +# Runs on pull requests and on the branches they merge into, so a green tick means the code was +# checked in the state it will actually land in. `develop` is where work integrates and `main` is +# what it is promoted to; a merge into either is a state nothing else would otherwise check, +# since a pull request is checked before the merge rather than after it. on: push: - branches: [main] + branches: [main, develop] pull_request: # A second push to the same branch makes the first run's answer irrelevant.