Github Actions工作流在非预期分支被触发问题求助

原因分析 #

你遇到的问题核心在于GitHub Actions中pull_request事件的触发逻辑：

• pull_request字段下的branches指定的是PR的目标分支，而非源分支。如果当前仓库存在从develop分支向main分支发起的PR，那么任何对develop分支的推送（包括更新该PR的提交）都会触发这个监听main分支作为PR目标的工作流——因为GitHub会将PR源分支的更新视为针对目标分支PR事件的一部分。
• 额外需要确认：你的main.yml工作流文件是否同时存在于develop分支中？如果是，GitHub Actions会执行当前推送分支下的工作流配置，但结合你的描述，核心原因还是PR目标分支的触发逻辑。

解决方法 #

1. 调整生产环境工作流的pull_request触发条件 #

如果你只希望在PR被合并到main分支时才触发生产部署，而非PR源分支更新时就触发，可以给pull_request事件添加types限制，只监听合并动作：

name: Create and Upload Prod Container and Deploy to Prod Amazon ECS

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
    types: [closed] # 仅当PR关闭（含合并）时触发

jobs:
  deploy:
    if: github.event.pull_request.merged == true # 确保仅合并动作触发部署
    # 后续部署步骤

2. 拆分工作流，区分生产与开发环境 #

为了更清晰地管理不同环境的部署，建议拆分两个独立的工作流文件：

• 生产环境工作流（如.github/workflows/prod.yml）：保持原有的push: main触发逻辑，结合上述调整控制PR触发时机。
• 开发环境工作流（如.github/workflows/dev.yml）：专门监听带有develop标识的分支的推送：

name: Create and Upload Dev Container and Deploy to Dev Amazon ECS

on:
  push:
    branches:
      - '*develop*' # 匹配所有含develop的分支，如develop、feature/develop-xxx等

这种方式可以彻底避免不同环境工作流的触发冲突，同时更符合CI/CD的分层管理逻辑。

内容的提问来源于stack exchange，提问作者Juan Diego