github-actions

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitHub Actions Pipeline

GitHub Actions 流水线

Use GitHub Actions as the primary CI/CD platform
Trigger on
```
push
```
to
```
main
```
and on all Pull Requests
Pipeline MUST include these stages in order:

使用 GitHub Actions 作为主要的 CI/CD 平台
在向
```
main
```
分支推送代码以及所有 Pull Request 时触发流水线
流水线必须按顺序包含以下阶段：

Stage 1: Quality Gate

阶段1：质量门禁

yaml

- name: Analyze
  run: flutter analyze --fatal-infos --fatal-warnings
- name: Format Check
  run: dart format --set-exit-if-changed .
- name: Run Tests
  run: flutter test --coverage

Zero warnings policy —
```
--fatal-infos
```
ensures no info-level issues pass
Format check MUST use
```
--set-exit-if-changed
```
to enforce consistent formatting

yaml

- name: Analyze
  run: flutter analyze --fatal-infos --fatal-warnings
- name: Format Check
  run: dart format --set-exit-if-changed .
- name: Run Tests
  run: flutter test --coverage

零警告策略——
```
--fatal-infos
```
确保没有信息级别的问题通过
格式检查必须使用
```
--set-exit-if-changed
```
来强制执行统一的代码格式

Stage 2: Build

阶段2：构建

yaml

- name: Build APK
  run: flutter build apk --flavor prod --dart-define-from-file=config/prod.json --release
- name: Build IPA
  run: flutter build ipa --flavor prod --dart-define-from-file=config/prod.json --release --export-options-plist=ios/ExportOptions.plist

Always build with

--flavor prod

and

--dart-define-from-file=config/prod.json

Use a single
```
main.dart
```
— do NOT pass
```
-t lib/main_prod.dart
```

yaml

- name: Build APK
  run: flutter build apk --flavor prod --dart-define-from-file=config/prod.json --release
- name: Build IPA
  run: flutter build ipa --flavor prod --dart-define-from-file=config/prod.json --release --export-options-plist=ios/ExportOptions.plist

始终使用

--flavor prod

和

--dart-define-from-file=config/prod.json

进行构建

使用单一的
```
main.dart
```
——不要传入
```
-t lib/main_prod.dart
```

Stage 3: Deploy (on main merge only)

阶段3：部署（仅在合并到main分支时执行）

Upload to Firebase App Distribution for internal testing
Upload to Google Play Internal Track / TestFlight for staging
Production release requires manual approval gate

上传到 Firebase App Distribution 进行内部测试
上传到 Google Play 内部测试轨道 / TestFlight 进行预发布测试
生产环境发布需要手动审批环节

Versioning Strategy

版本控制策略

Follow Semantic Versioning:
```
MAJOR.MINOR.PATCH+BUILD
```
Bump
```
PATCH
```
for bug fixes,
```
MINOR
```
for features,
```
MAJOR
```
for breaking changes
Set version in
```
pubspec.yaml
```
:
```
version: 1.2.3+45
```
The
```
+BUILD
```
number MUST auto-increment in CI (use build number from CI environment)

遵循语义化版本控制（Semantic Versioning）：
```
MAJOR.MINOR.PATCH+BUILD
```
修复 bug 时升级
```
PATCH
```
版本，新增功能时升级
```
MINOR
```
版本，有破坏性变更时升级
```
MAJOR
```
版本
在
```
pubspec.yaml
```
中设置版本：
```
version: 1.2.3+45
```
```
+BUILD
```
编号必须在CI中自动递增（使用CI环境中的构建编号）

Code Signing

代码签名

Store signing keys and certificates in GitHub Secrets (never in repo)
Android: Store keystore as base64-encoded secret, decode in CI
iOS: Use App Store Connect API key for automated signing
NEVER commit
```
*.jks
```
,
```
*.keystore
```
,
```
*.p12
```
, or
```
*.mobileprovision
```
files

将签名密钥和证书存储在 GitHub Secrets 中（绝不要存入代码仓库）
Android：将 keystore 作为 base64 编码的密钥存储，在CI中解码使用
iOS：使用 App Store Connect API 密钥进行自动签名
绝不要提交
```
*.jks
```
、
```
*.keystore
```
、
```
*.p12
```
或
```
*.mobileprovision
```
文件

PR Requirements

Pull Request 要求

All PRs MUST pass: analysis (0 warnings), formatting, and tests before merge
Require at least 1 code review approval
Branch protection on
```
main
```
: no direct pushes, require status checks

所有 PR 在合并前必须通过：代码分析（零警告）、格式检查和测试
至少需要1次代码审核通过
```
main
```
分支保护：禁止直接推送代码，必须通过状态检查

Release Checklist

发布检查清单

Version bumped in
```
pubspec.yaml
```
CHANGELOG.md updated
All tests passing on CI
Build succeeds for both Android and iOS
Tested on physical device with production flavor
Git tag created matching version (
```
v1.2.3
```
)

```
pubspec.yaml
```
中的版本已更新
CHANGELOG.md 已更新
CI上所有测试通过
Android和iOS的构建均成功
已使用生产环境 flavor 在物理设备上测试
已创建与版本匹配的Git标签（
```
v1.2.3
```
）