boardx / boardx/workspacex

chore(ci): 每个 PR 都部署到 devops,取消 tag 触发

Open
#482 0 comments 0 reactions 0 assignees View on GitHub
out-of-scope owner:coord-architecture sprint-2
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
1h 7m
Merged PRs (30d)
969

Description

## 人类决定(2026-08-05)

> 对于 github workflow,改为每次 PR 都发布新版本到 devops 而不要用 tag

## 现状

`.github/workflows/backend-gates.yml` 的 `deploy` job:

```yaml
deploy:
needs: gates
# 只有打标签才部署。标签是人的显式动作……
if: startsWith(github.ref, 'refs/tags/v')
run: bash .harness/scripts/vm/deploy-gate.sh "${{ github.ref_name }}"
```

且整个 workflow **没有 `pull_request` 触发**(只有 `push: tags/branches[main]` + `workflow_dispatch`),尽管 `gates` job 的 `if` 里早就写了 fork PR 的防线,说明 PR 触发是原本预期内的。

## 范围

1. 给 `backend-gates.yml` 加 `pull_request` 触发;去掉 `tags: ["v*"]` 这条部署入口。
2. `deploy` 的条件从「打了 `v*` 标签」改为「同仓 PR、或 push 到 main、或手动」。
3. 部署的 git-ref 从 `github.ref_name`(标签名)改为 **PR head SHA**(push 时为 `github.sha`)——`deploy.sh` 走的是 `git fetch origin ` + `git reset --hard `,SHA 是最精确、无歧义的输入。
4. **部署必须全局串行**:`devops` 是**一台**机器,`deploy.sh` 会 `git reset --hard`。现有 concurrency 按 `github.ref` 分组,两个 PR 会并发往同一台机器上 reset。给 `deploy` job 单独一条全局 concurrency 泳道。

## 必须保持的安全边界(不得随本次改动放宽)

- **fork PR 一律不部署**。self-hosted runner + `sudo /usr/local/bin/workspacex-deploy`,接受 fork 等于任何人提个 PR 就能在那台机器上以 root 跑代码。`gates` 已有这条防线,`deploy` 必须同样显式写出,不能只靠 `needs: gates` 隐含。
- 仍走 `/usr/local/bin` 的副本而不是仓库里那份 `deploy.sh`(sudoers 只许那一条路径)。

## 人类需要知道的后果(不是反对,是如实说明)

每个 PR 都部署到同一台 `devops` 之后:

1. 那台机器上跑的**不再是 main,而是"最后一个部署过的 PR"**。谁在上面看到的东西取决于时序。
2. PR 合并/关闭后,它部署的那一版**不会自动撤回**——机器会停在那个 PR 的代码上,直到下一次部署。
3. 两个 PR 先后部署时,后者覆盖前者;串行化只保证不撕裂,不保证"你看到的是你的那版"。

如果需要「每个 PR 一个独立环境」或「合并后自动回到 main」,那是另一条 issue(预览环境 / 合并后自动重部署),本条不顺带做。

## 验收

- 反证:伪造一个 fork PR 事件负载 → `deploy` 的条件求值为 false。
- 反证:条件里去掉同仓判断 → 该反证变绿(证明这条断言不是空转)。
- workflow 语法可解析;`gates` 仍是 `deploy` 的前置。

**Owner**:coord-architecture

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with .github/workflows/backend-gates.yml and the referenced .harness/scripts/vm/deploy-gate.sh; inspect deploy.sh’s fetch and reset behavior to confirm the required ref input. Check the workflow syntax and evaluate the deploy condition with same-repository and fork pull request events. Done means pull requests deploy serially using the intended ref, fork deployments remain blocked, and gates still precedes deploy.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, devops
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
64/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.