Setup/cd workflow#3
Merged
Merged
Conversation
Contributor
Руководство для рецензентаДобавляет workflow развёртывания GitHub Actions, который подключается через Tailscale и выполняет деплой на удалённый сервер по SSH при пушах в main, включая управление конкурентностью и шаги деплоя на базе Docker. Диаграмма последовательности для workflow Deploy при push в mainsequenceDiagram
actor Developer
participant GitHubRepo
participant GitHubActions
participant Tailscale
participant RemoteServer
participant DockerEngine
Developer->>GitHubRepo: push commit to main
GitHubRepo->>GitHubActions: trigger Deploy workflow (on push to main)
GitHubActions->>GitHubActions: create concurrency group deploy-${{ github.ref }}
GitHubActions->>GitHubActions: cancel in-progress deploy jobs for same ref
GitHubActions->>Tailscale: connect using secret TAILSCALE_AUTHKEY
Tailscale-->>GitHubActions: runner joined Tailscale network
GitHubActions->>RemoteServer: SSH using SSH_USER and SSH_DEPLOY_PRIVATE_KEY
GitHubActions->>RemoteServer: run cd ~/SteelTime
GitHubActions->>RemoteServer: run git fetch origin main
GitHubActions->>RemoteServer: run git reset --hard origin/main
GitHubActions->>RemoteServer: run docker compose up -d --build
RemoteServer->>DockerEngine: build and start containers
GitHubActions->>RemoteServer: run docker system prune -f
Изменения на уровне файлов
Подсказки и командыВзаимодействие с Sourcery
Настройка работы сервисаЗайдите в свою панель управления, чтобы:
Получение помощи
Original review guide in EnglishReviewer's GuideAdds a GitHub Actions deployment workflow that connects via Tailscale and deploys to a remote server over SSH on pushes to main, including concurrency control and Docker-based deployment steps. Sequence diagram for Deploy workflow on push to mainsequenceDiagram
actor Developer
participant GitHubRepo
participant GitHubActions
participant Tailscale
participant RemoteServer
participant DockerEngine
Developer->>GitHubRepo: push commit to main
GitHubRepo->>GitHubActions: trigger Deploy workflow (on push to main)
GitHubActions->>GitHubActions: create concurrency group deploy-${{ github.ref }}
GitHubActions->>GitHubActions: cancel in-progress deploy jobs for same ref
GitHubActions->>Tailscale: connect using secret TAILSCALE_AUTHKEY
Tailscale-->>GitHubActions: runner joined Tailscale network
GitHubActions->>RemoteServer: SSH using SSH_USER and SSH_DEPLOY_PRIVATE_KEY
GitHubActions->>RemoteServer: run cd ~/SteelTime
GitHubActions->>RemoteServer: run git fetch origin main
GitHubActions->>RemoteServer: run git reset --hard origin/main
GitHubActions->>RemoteServer: run docker compose up -d --build
RemoteServer->>DockerEngine: build and start containers
GitHubActions->>RemoteServer: run docker system prune -f
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey — я нашёл 3 проблемы и оставил несколько общих комментариев:
- Параметр
authkeyдля экшена Tailscale должен использовать синтаксис выражений GitHub (например,authkey: ${{ secrets.TAILSCALE_AUTHKEY }}), а не YAML‑якорь в стиле&{{ ... }}, который не будет работать как ожидается. - Рассмотрите возможность вынести жёстко прописанный IP сервера (
107.74.35.34) в секрет или переменную окружения, чтобы его можно было менять без правки файла workflow и чтобы не раскрывать детали инфраструктуры в репозитории. - Команда
docker system prune -fв скрипте деплоя может удалять образы и ресурсы, не связанные с этим развёртыванием; имеет смысл ограничить очистку конкретными контейнерами/образами или вынести периодическое обслуживание отдельно от workflow деплоя.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `authkey` parameter for the Tailscale action should use GitHub expression syntax (e.g. `authkey: ${{ secrets.TAILSCALE_AUTHKEY }}`) rather than the YAML anchor-style `&{{ ... }}`, which will not resolve as intended.
- Consider moving the hard-coded server IP (`107.74.35.34`) into a secret or environment variable so it can be changed without editing the workflow file and to avoid exposing infrastructure details in the repo.
- `docker system prune -f` in the deploy script can remove images and resources unrelated to this deployment; consider limiting cleanup to specific containers/images or running periodic maintenance separately from the deployment workflow.
## Individual Comments
### Comment 1
<location path=".github/workflows/deploy.yml" line_range="20" />
<code_context>
+ - name: Connect to tailscale
+ uses: tailscale/github-action@v2
+ with:
+ authkey: &{{ secrets.TAILSCALE_AUTHKEY }}
+
+ - name: Deploy to server
</code_context>
<issue_to_address>
**issue (bug_risk):** GitHub Actions expression syntax for `authkey` looks incorrect and will likely fail parsing.
The `authkey` line is using `&{{ ... }}`, which is a YAML anchor, not valid GitHub Actions expression syntax, and will likely fail at parse or runtime. It should be:
```yaml
authkey: ${{ secrets.TAILSCALE_AUTHKEY }}
```
This aligns with other `secrets.*` usages and the expected input format for `tailscale/github-action`.
</issue_to_address>
### Comment 2
<location path=".github/workflows/deploy.yml" line_range="25" />
<code_context>
+ - name: Deploy to server
+ uses: appleboy/ssh-action@v1.0.0
+ with:
+ host: 107.74.35.34
+ username: ${{ secrets.SSH_USER }}
+ key: ${{ secrets.SSH_DEPLOY_PRIVATE_KEY }}
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Hardcoding the SSH host IP reduces flexibility and can leak infrastructure details.
Using a literal IP here makes it harder to rotate servers or separate environments, and it exposes infrastructure details in the repo. Prefer sourcing this from a secret or environment variable (e.g. `host: ${{ secrets.SSH_HOST }}`) so you can change hosts without code changes and avoid publishing the IP.
Suggested implementation:
```
- name: Deploy to server
uses: appleboy/ssh-action@v1.0.0
with:
host: ${{ secrets.SSH_HOST }}
username: ${{ secrets.SSH_USER }}
key: ${{ secrets.SSH_DEPLOY_PRIVATE_KEY }}
```
1. In your GitHub repository settings, define a `SSH_HOST` secret with the appropriate host (IP or hostname) for this deployment.
2. If you have multiple environments (e.g. staging/production), consider separate workflows or environment-specific secrets like `STAGING_SSH_HOST` and `PROD_SSH_HOST`.
</issue_to_address>
### Comment 3
<location path=".github/workflows/deploy.yml" line_range="33" />
<code_context>
+ git fetch origin main
+ git reset --hard origin/main
+ docker compose up -d --build
+ docker system prune -f
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Unscoped `docker system prune -f` can remove unrelated images/containers on the host.
On a shared host, this will remove all unused containers/images/networks, not just ones for this project, which can disrupt other services or wipe debugging artifacts. If you only need to clean up this project’s resources, consider a narrower command (e.g., `docker image prune` with labels/filters or `docker compose` cleanup) to avoid impacting unrelated workloads.
</issue_to_address>Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Original comment in English
Hey - I've found 3 issues, and left some high level feedback:
- The
authkeyparameter for the Tailscale action should use GitHub expression syntax (e.g.authkey: ${{ secrets.TAILSCALE_AUTHKEY }}) rather than the YAML anchor-style&{{ ... }}, which will not resolve as intended. - Consider moving the hard-coded server IP (
107.74.35.34) into a secret or environment variable so it can be changed without editing the workflow file and to avoid exposing infrastructure details in the repo. docker system prune -fin the deploy script can remove images and resources unrelated to this deployment; consider limiting cleanup to specific containers/images or running periodic maintenance separately from the deployment workflow.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `authkey` parameter for the Tailscale action should use GitHub expression syntax (e.g. `authkey: ${{ secrets.TAILSCALE_AUTHKEY }}`) rather than the YAML anchor-style `&{{ ... }}`, which will not resolve as intended.
- Consider moving the hard-coded server IP (`107.74.35.34`) into a secret or environment variable so it can be changed without editing the workflow file and to avoid exposing infrastructure details in the repo.
- `docker system prune -f` in the deploy script can remove images and resources unrelated to this deployment; consider limiting cleanup to specific containers/images or running periodic maintenance separately from the deployment workflow.
## Individual Comments
### Comment 1
<location path=".github/workflows/deploy.yml" line_range="20" />
<code_context>
+ - name: Connect to tailscale
+ uses: tailscale/github-action@v2
+ with:
+ authkey: &{{ secrets.TAILSCALE_AUTHKEY }}
+
+ - name: Deploy to server
</code_context>
<issue_to_address>
**issue (bug_risk):** GitHub Actions expression syntax for `authkey` looks incorrect and will likely fail parsing.
The `authkey` line is using `&{{ ... }}`, which is a YAML anchor, not valid GitHub Actions expression syntax, and will likely fail at parse or runtime. It should be:
```yaml
authkey: ${{ secrets.TAILSCALE_AUTHKEY }}
```
This aligns with other `secrets.*` usages and the expected input format for `tailscale/github-action`.
</issue_to_address>
### Comment 2
<location path=".github/workflows/deploy.yml" line_range="25" />
<code_context>
+ - name: Deploy to server
+ uses: appleboy/ssh-action@v1.0.0
+ with:
+ host: 107.74.35.34
+ username: ${{ secrets.SSH_USER }}
+ key: ${{ secrets.SSH_DEPLOY_PRIVATE_KEY }}
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Hardcoding the SSH host IP reduces flexibility and can leak infrastructure details.
Using a literal IP here makes it harder to rotate servers or separate environments, and it exposes infrastructure details in the repo. Prefer sourcing this from a secret or environment variable (e.g. `host: ${{ secrets.SSH_HOST }}`) so you can change hosts without code changes and avoid publishing the IP.
Suggested implementation:
```
- name: Deploy to server
uses: appleboy/ssh-action@v1.0.0
with:
host: ${{ secrets.SSH_HOST }}
username: ${{ secrets.SSH_USER }}
key: ${{ secrets.SSH_DEPLOY_PRIVATE_KEY }}
```
1. In your GitHub repository settings, define a `SSH_HOST` secret with the appropriate host (IP or hostname) for this deployment.
2. If you have multiple environments (e.g. staging/production), consider separate workflows or environment-specific secrets like `STAGING_SSH_HOST` and `PROD_SSH_HOST`.
</issue_to_address>
### Comment 3
<location path=".github/workflows/deploy.yml" line_range="33" />
<code_context>
+ git fetch origin main
+ git reset --hard origin/main
+ docker compose up -d --build
+ docker system prune -f
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Unscoped `docker system prune -f` can remove unrelated images/containers on the host.
On a shared host, this will remove all unused containers/images/networks, not just ones for this project, which can disrupt other services or wipe debugging artifacts. If you only need to clean up this project’s resources, consider a narrower command (e.g., `docker image prune` with labels/filters or `docker compose` cleanup) to avoid impacting unrelated workloads.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Deployment:
main.Original summary in English
Summary by Sourcery
Deployment: