ci: add auto-deploy to S1+S2 via rsync after merge #3

Merged

min merged 2 commits from chore/ci-deploy-to-s1-s2 into main 2026-05-29 01:10:06 +00:00

Conversation 0 Commits 2 Files Changed 2 +120 -3

min commented 2026-05-28 23:53:45 +00:00

Owner

Copy Link

Что

Добавляет CI-job deploy в .gitea/workflows/ci.yml — после успешного мержа в main билдит прод-бандл и параллельно заливает на S1 + S2 через rsync.

Также обновляет CONTRIBUTING.md:

• секция "Для мейнтейнеров (включая Lead)" — почему даже Lead идёт через PR
• hotfix-flow (всегда через PR, не прямой push)
• DevPanel как fallback если CI deploy сломался

Зачем

До этого PR деплоились вручную через DevPanel. Это работало, но:

• легко забыть задеплоить на один из серверов (теперь оба auto)
• ручной деплой не привязан к коммиту (нет audit trail)
• разные разработчики могли деплоить разные ветки

Теперь любое изменение в main → автоматический деплой на оба сервера.

Как протестить

Этот PR сам себя протестирует: после мержа CI запустит deploy-job и зальёт текущий код студии на прод. Если что-то сломается — откатить через git revert + новый PR.

Чек-лист

• Lint проходит
• Build проходит
• DEPLOY_SSH_KEY и KNOWN_HOSTS secrets уже залиты в Gitea
• Pubkey установлен на ~min/.ssh/authorized_keys на обеих VM 124

## Что Добавляет CI-job `deploy` в `.gitea/workflows/ci.yml` — после успешного мержа в main билдит прод-бандл и параллельно заливает на S1 + S2 через rsync. Также обновляет `CONTRIBUTING.md`: - секция "Для мейнтейнеров (включая Lead)" — почему даже Lead идёт через PR - hotfix-flow (всегда через PR, не прямой push) - DevPanel как fallback если CI deploy сломался ## Зачем До этого PR деплоились вручную через DevPanel. Это работало, но: - легко забыть задеплоить на один из серверов (теперь оба auto) - ручной деплой не привязан к коммиту (нет audit trail) - разные разработчики могли деплоить разные ветки Теперь любое изменение в main → автоматический деплой на оба сервера. ## Как протестить Этот PR сам себя протестирует: после мержа CI запустит deploy-job и зальёт текущий код студии на прод. Если что-то сломается — откатить через `git revert` + новый PR. ## Чек-лист - [x] Lint проходит - [x] Build проходит - [x] DEPLOY_SSH_KEY и KNOWN_HOSTS secrets уже залиты в Gitea - [x] Pubkey установлен на ~min/.ssh/authorized_keys на обеих VM 124

min added 1 commit 2026-05-28 23:53:46 +00:00

ci: add auto-deploy to S1+S2 via rsync after merge to main ... 9808c11467

Adds new "deploy" job in .gitea/workflows/ci.yml that runs on push
to main (after PR is merged). Builds production bundle and rsyncs
it to /var/www/rublox-player/build/ on both production servers
(S1 VM 124 via NAT 1998, S2 VM 124 directly via runner network).

Uses Gitea Secrets:
  - DEPLOY_SSH_KEY: dedicated ed25519 key for CI, pubkey already
    on ~min/.ssh/authorized_keys on both VM 124
  - KNOWN_HOSTS: host-keys of both targets to prevent MITM

Also updates CONTRIBUTING.md:
  - Maintainer workflow section explaining why even Lead works via PR
  - Hotfix flow (always via PR, never direct push to main)
  - DevPanel as fallback if CI deploy is broken

min force-pushed chore/ci-deploy-to-s1-s2 from 9808c11467 to b2c7edf46d 2026-05-29 00:44:59 +00:00 Compare

min force-pushed chore/ci-deploy-to-s1-s2 from b2c7edf46d to 63b3472b82 2026-05-29 00:55:13 +00:00 Compare

min added 1 commit 2026-05-29 01:09:00 +00:00

ci: re-trigger checks 210d26a3f8

min merged commit f2938ee072 into main 2026-05-29 01:10:06 +00:00

min referenced this issue from a commit 2026-05-29 01:10:07 +00:00

ci: add auto-deploy to S1+S2 via rsync after merge (#3)

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

min user7278

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rublox/player#3

No description provided.