Open
Conversation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/CD.yml:
- Line 13: The deploy step currently disables SSH host-key verification in the
command "ssh -o StrictHostKeyChecking=no deploy-user@${{ secrets.CONTAINER_IP }}
<< 'EOF'"; remove that option and instead ensure the target host key is added to
the runner's known_hosts before connecting (for example, run ssh-keyscan against
${{ secrets.CONTAINER_IP }} and append the output to ~/.ssh/known_hosts or store
the host's public key/fingerprint in a secret and write it to known_hosts), and
keep SSH configured with StrictHostKeyChecking=yes so the connection verifies
the host key; update the workflow to add this known_hosts population step prior
to invoking the ssh command and ensure permissions on ~/.ssh are correct.
- Around line 15-19: The workflow runs docker compose against the repository but
never syncs the working tree first; add a git sync step before the docker login
and docker compose commands to avoid using stale docker-compose.cd.yml or
scripts—e.g., run a git fetch and then git reset --hard origin/<branch> (or git
pull origin <branch>) in the deployment repo (use git -C if running from a
different cwd) so that the subsequent docker compose -f docker-compose.cd.yml
pull and docker compose -f docker-compose.cd.yml up -d operate on the latest
commit; ensure the branch comes from the workflow context (GITHUB_REF or a
workflow variable) rather than hardcoding.
In @.github/workflows/CI.yml:
- Around line 54-79: Replace the three image tags that currently push only
:latest in the "Build and Push API", "Build and Push Admin", and "Build and Push
Mobile" steps so artifacts are also tagged with a stable, unique identifier
(e.g., Git SHA or semantic tag) in addition to :latest; update the tags
parameter for the docker/build-push-action calls (the steps named "Build and
Push API", "Build and Push Admin", and "Build and Push Mobile") to include both
${{ secrets.HARBOR_REG }}/seeft/<service>:latest and a second tag such as ${{
secrets.HARBOR_REG }}/seeft/<service>:${{ github.sha }} (or a version variable)
so you can trace and roll back specific deployments.
- Around line 37-40: Replace the deprecated input name for the Buildx action: in
the docker/setup-buildx-action@v3 usage, change the input key from config-inline
to buildkitd-config-inline and pass the identical inline registry configuration
value; ensure any references to "config-inline" in that action step are updated
to "buildkitd-config-inline" so the "[registry.\"${{ secrets.HARBOR_REG }}\"]"
block continues to be applied to BuildKit.
- Around line 27-40: The workflow currently forces Docker to trust an insecure
registry by writing to /etc/docker/daemon.json (step "Configure Insecure
Registry") and by setting config-inline entries http = true and insecure = true
in the "Set up Docker Buildx" step; remove those changes and instead configure
the runner to use a secure registry: stop writing an insecure daemon.json,
remove the config-inline http/insecure flags, and ensure Docker trust is
configured by adding the registry's CA into
/etc/docker/certs.d/<registry>/ca.crt (or use a properly TLS-enabled registry)
and perform a normal docker login with the existing secrets; update the
"Configure Insecure Registry" and "Set up Docker Buildx" steps to rely on TLS
and credentials rather than enabling insecure/http options.
- Around line 49-52: In the "Create .env file" workflow step, replace the use of
echo for writing the secret SEEFT_MOBILE_ENVS with a call to printf so the
secret's multiline content and trailing newlines/spaces are preserved when
writing to mobile/env/.env; keep the mkdir -p mobile/env step, and ensure the
secret is redirected into mobile/env/.env using printf under a POSIX shell
(e.g., bash) rather than echo.
In `@docker-compose.cd.yml`:
- Line 24: The docker-compose service uses env_file "./api/env/seeft.env" which
isn't present in the repo and will break docker compose; update the env_file
entry in docker-compose.cd.yml to point to an existing tracked file (e.g.,
"./api/env/dev.env") or add a safe fallback mechanism (like referencing an
.env.example or making the env_file optional via documentation/compose override)
so docker compose up won't fail when seeft.env is not provisioned.
- Line 31: The service command currently runs "sh -c \"npm install && npm run
build && npm run start\"" at container start; change it to only run the prebuilt
start command (e.g., "npm run start" or the production node entrypoint) and
ensure the image is built with dependencies and the production build in the
Dockerfile/CI pipeline instead of installing/building at runtime; update the
docker-compose service to remove "npm install" and "npm run build" from the
command and verify the Dockerfile produces the built app and proper
CMD/ENTRYPOINT so the compose file just invokes the runtime start command.
- Around line 22-23: The docker-compose.cd.yml currently bind-mounts the source
(volumes: ["./api:/env/app"]) and runs a build at container start (command: sh
-c "go build -o main main.go && ./main"), which violates immutable deploys and
requires the Go toolchain at runtime; remove the bind-mount and replace the
runtime command so the container runs the prebuilt artifact produced by CI
(e.g., drop volumes: ["./api:/env/app"] and change the command to just run the
compiled binary such as ./main or rely on the image's CMD), and ensure the CI
pipeline builds a multi-stage Docker image that contains the compiled binary
referenced by this compose file instead of compiling in the container.
- Around line 41-44: The compose file sets the network as external
(networks.default with name: seeft-default and external: true), which prevents
Docker from creating it and will break deploys where that network doesn't
pre-exist; either remove external: true so Compose will create the network
automatically, or add logic to the deployment/initialization scripts to create
the named network (seeft-default) beforehand (e.g., docker network create) and
document that step—update the compose or the deploy scripts consistently so
deployments won't fail when seeft-default is missing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 051419f9-f03e-4fc6-91d3-f67ba82b3444
📒 Files selected for processing (3)
.github/workflows/CD.yml.github/workflows/CI.ymldocker-compose.cd.yml
Comment on lines
+54
to
+79
| - name: Build and Push API | ||
| uses: docker/build-push-action@v5 | ||
| with: | ||
| context: ./api | ||
| file: ./api/prod.Dockerfile | ||
| push: true | ||
| tags: ${{ secrets.HARBOR_REG }}/seeft/api:latest | ||
| cache-from: type=gha | ||
|
|
||
| - name: Build and Push Admin | ||
| uses: docker/build-push-action@v5 | ||
| with: | ||
| context: ./admin | ||
| file: ./admin/prod.Dockerfile | ||
| push: true | ||
| tags: ${{ secrets.HARBOR_REG }}/seeft/admin:latest | ||
| cache-from: type=gha | ||
|
|
||
| - name: Build and Push Mobile | ||
| uses: docker/build-push-action@v5 | ||
| with: | ||
| context: ./mobile | ||
| file: ./mobile/Dockerfile | ||
| push: true | ||
| tags: ${{ secrets.HARBOR_REG }}/seeft/mobile:latest | ||
| cache-from: type=gha |
There was a problem hiding this comment.
Avoid latest-only tagging for production deploy artifacts.
Lines 60, 69, and 78 publish only :latest, which makes rollback and incident traceability difficult.
Suggested fix
+ - name: Set image tag
+ run: echo "IMAGE_TAG=${GITHUB_SHA}" >> $GITHUB_ENV
+
- name: Build and Push API
uses: docker/build-push-action@v5
with:
context: ./api
file: ./api/prod.Dockerfile
push: true
- tags: ${{ secrets.HARBOR_REG }}/seeft/api:latest
+ tags: |
+ ${{ secrets.HARBOR_REG }}/seeft/api:${{ env.IMAGE_TAG }}
+ ${{ secrets.HARBOR_REG }}/seeft/api:latest
cache-from: type=gha🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/CI.yml around lines 54 - 79, Replace the three image tags
that currently push only :latest in the "Build and Push API", "Build and Push
Admin", and "Build and Push Mobile" steps so artifacts are also tagged with a
stable, unique identifier (e.g., Git SHA or semantic tag) in addition to
:latest; update the tags parameter for the docker/build-push-action calls (the
steps named "Build and Push API", "Build and Push Admin", and "Build and Push
Mobile") to include both ${{ secrets.HARBOR_REG }}/seeft/<service>:latest and a
second tag such as ${{ secrets.HARBOR_REG }}/seeft/<service>:${{ github.sha }}
(or a version variable) so you can trace and roll back specific deployments.
There was a problem hiding this comment.
@FastDefence 良い質問です。結論から言うと、SHA タグも付与する場合は、今まで通り GC だけでは古いイメージが自動削除されません。
Harbor GC の動作について
Harbor でイメージを削除しても、ストレージはすぐに解放されません。GC を実行することで、マニフェストから参照されなくなったブロブ（blob）がファイルシステムから削除されます。
:latest のみの現状では、以下の流れになります：
- 新しいビルドを push すると、
:latestタグが新しいマニフェストに移動する - Harbor では同じタグで繰り返し push が可能で、タグは新しいアーティファクトに移動し、タグを失った古いアーティファクトは「タグなし（tagless）」になります。
- GC 実行時に
delete_untagged = trueであれば、タグなし artifact が削除される → 今まで通りの動作
:sha + :latest の両方を付与した場合は、挙動が変わります：
:latestは新しいイメージに移動し、旧マニフェストからは外れる- しかし旧マニフェストには
:shaタグが残ったままのため、「タグなし」にはならない - GC はタグが付いているアーティファクトを削除しないため、SHA タグ付きの古いイメージはどんどん蓄積します
解決策
SHA タグ付きイメージを自動的に削除するには、Tag Retention Rules（タグ保持ポリシー） を Harbor の UI で設定する必要があります。
リポジトリには多数のイメージタグが急速に蓄積されることがあり、それらは大量のストレージを消費します。
Harbor システム管理者は、リポジトリに対して特定のタグをどれだけ保持するかのルールを定義できます。ルールはプロジェクト単位ではなくリポジトリ単位で定義します。
設定例：「最新 N 件のタグのみ保持」というルールを各リポジトリに設定することで、古い SHA タグのイメージを自動削除できます。
⚠️ ただし、既知の問題として、複数のタグが同じ SHA ダイジェストを参照している場合、削除対象のタグのサブセットが存在すると、残りのタグもすべて削除されてしまうことがあります。そのため、この場合はすべてのタグが保持される可能性があります。
まとめ
| タグ構成 | GC だけで古いイメージが削除されるか |
|---|---|
:latest のみ（現状） |
✅ delete_untagged=true で削除される |
:sha + :latest |
❌ SHA タグが残るため GC では削除されない → Tag Retention Rules が別途必要 |
SHA タグを導入するのであれば、Harbor の 「Tag Retention」 機能で「最新 N 件のみ保持」ポリシーを設定することを推奨します。
🧠 Learnings used
Learnt from: FastDefence
Repo: NUTFes/SeeFT PR: 262
File: .github/workflows/CI.yml:27-40
Timestamp: 2026-04-18T19:58:59.501Z
Learning: For the SeeFT CI workflow at .github/workflows/CI.yml, allow the Harbor registry URL to be configured with an insecure/HTTP scheme in the CI job because all registry communication occurs via the Tailscale VPN (WireGuard-encrypted overlay). Do not raise a security finding solely due to insecure registry settings in this workflow, as the traffic is not exposed outside the encrypted tunnel.
Comment on lines
+22
to
+23
| volumes: ["./api:/env/app"] | ||
| command: sh -c "go build -o main main.go && ./main" |
There was a problem hiding this comment.
Don’t compile Go at container startup in CD compose.
Lines 22-23 bind-mount source and run go build on startup, which breaks immutable-deploy assumptions and can fail if runtime image lacks toolchain.
Suggested direction
api:
image: ${HARBOR_REG}/seeft/api:latest
container_name: "nutfes-seeft-api"
- volumes: ["./api:/env/app"]
- command: sh -c "go build -o main main.go && ./main"
+ # rely on the image artifact built in CI
+ # command should be provided by Dockerfile CMD/ENTRYPOINT
env_file: ["./api/env/seeft.env"]
ports: ["1234:1234"]
restart: always🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docker-compose.cd.yml` around lines 22 - 23, The docker-compose.cd.yml
currently bind-mounts the source (volumes: ["./api:/env/app"]) and runs a build
at container start (command: sh -c "go build -o main main.go && ./main"), which
violates immutable deploys and requires the Go toolchain at runtime; remove the
bind-mount and replace the runtime command so the container runs the prebuilt
artifact produced by CI (e.g., drop volumes: ["./api:/env/app"] and change the
command to just run the compiled binary such as ./main or rely on the image's
CMD), and ensure the CI pipeline builds a multi-stage Docker image that contains
the compiled binary referenced by this compose file instead of compiling in the
container.
There was a problem hiding this comment.
@FastDefence はい、まさにその通りです！マルチステージビルドを使って prod.Dockerfile 内でコンパイルするのがベストプラクティスです。
なぜ Dockerfile 内でビルドすべきか
| 現状の問題 | Dockerfile 内でビルドした場合 |
|---|---|
| ランタイムイメージに Go ツールチェーンが必要 | 最終イメージに Go ツールチェーン不要（軽量化） |
| 起動のたびにビルドが走り、起動が遅い | CI でビルド済みのバイナリを実行するだけで高速 |
| ソースコードをサーバにマウントする必要がある | イメージが自己完結（immutable deploy） |
api/prod.Dockerfile の修正例（マルチステージビルド）
# --- ビルドステージ ---
FROM golang:1.23-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o main main.go
# --- ランタイムステージ ---
FROM alpine:3.20
WORKDIR /app
COPY --from=builder /app/main .
EXPOSE 1234
CMD ["./main"]docker-compose.cd.yml の修正例
api:
image: ${HARBOR_REG}/seeft/api:latest
container_name: "nutfes-seeft-api"
# volumes と command を削除 — Dockerfile の CMD に委ねる
env_file: ["./api/env/seeft.env"]
ports: ["1234:1234"]
restart: alwaysvolumes: ["./api:/env/app"] と command: sh -c "go build ..." を削除することで、CI でビルドされたイメージをそのまま実行するだけになります。seeft.env は引き続きサーバ上のファイルから読み込まれる設計のままです（既存の学習内容と一致）。
(ﾉ´ヮ´)ﾉ*:･ﾟ✧
🧠 Learnings used
Learnt from: FastDefence
Repo: NUTFes/SeeFT PR: 262
File: docker-compose.cd.yml:24-24
Timestamp: 2026-04-18T19:42:09.584Z
Learning: In the SeeFT repository, `api/env/seeft.env` is intentionally NOT tracked in git. It is a production secret environment file that is manually provisioned directly on the deployment server (`/home/deploy-user/SeeFT`). The `docker-compose.cd.yml` file references it via `env_file: ["./api/env/seeft.env"]` and this is by design — do not flag it as a missing or untracked file in future reviews.
| admin: | ||
| image: ${HARBOR_REG}/seeft/admin:latest | ||
| container_name: "nutfes-seeft-admin" | ||
| command: sh -c "npm install && npm run build && npm run start" |
There was a problem hiding this comment.
Avoid runtime npm install/build in production container start command.
Line 31 makes startup dependent on live package install/build, increasing failure risk and startup time. Prefer running only the prebuilt app command from the image.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docker-compose.cd.yml` at line 31, The service command currently runs "sh -c
\"npm install && npm run build && npm run start\"" at container start; change it
to only run the prebuilt start command (e.g., "npm run start" or the production
node entrypoint) and ensure the image is built with dependencies and the
production build in the Dockerfile/CI pipeline instead of installing/building at
runtime; update the docker-compose service to remove "npm install" and "npm run
build" from the command and verify the Dockerfile produces the built app and
proper CMD/ENTRYPOINT so the compose file just invokes the runtime start
command.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find prod.Dockerfile for admin
fd -i "prod.Dockerfile" --exec echo {}
fd -i "Dockerfile" --exec echo {}
Length of output: 147
🏁 Script executed:
#!/bin/bash
cat ./admin/prod.Dockerfile
echo "---"
cat ./admin/Dockerfile
Length of output: 283
@FastDefence はい、Dockerfile内でビルドするのが正しいアプローチです。
現在の admin/prod.Dockerfile を確認すると、npm install や npm run build が実行されておらず、CMD/ENTRYPOINT も設定されていないため、docker-compose 側でそれらを補っている状態になっています。
以下のように prod.Dockerfile に RUN と CMD を追加することを推奨します：
# admin/prod.Dockerfile
FROM node:16.13.0
WORKDIR /app/next-project/seeft-admin
COPY ./ /app
ENV NEXT_PUBLIC_APP_ENV production
# ← ここでビルドまで完結させる
RUN npm ci && npm run build
CMD ["npm", "run", "start"]そして docker-compose.cd.yml の admin サービスから command を削除します：
admin:
image: ${HARBOR_REG}/seeft/admin:latest
container_name: "nutfes-seeft-admin"
# command は不要（DockerfileのCMDが使われる）
ports: ["5000:3000"]
environment:
NEXT_PUBLIC_APP_ENV: "production"
stdin_open: true
tty: true
depends_on: ["api"]
restart: alwaysこの変更のメリット：
| 現在（runtime build） | 改善後（image build） | |
|---|---|---|
| 起動時間 | 遅い（install+buildが毎回走る） | 速い（起動のみ） |
| 障害リスク | npm registry障害で起動失敗の可能性 | イメージ作成時に完結 |
| 再現性 | コンテナ毎に差異が出うる | CIでビルドしたものがそのまま動く |
| イメージサイズ | ビルドキャッシュが残る | multi-stage buildでさらに削減可能 |
なお、api サービスの command: sh -c "go build -o main main.go && ./main" も同様の問題があります。api/prod.Dockerfile にも RUN go build -o main main.go と CMD ["./main"] を追加することをお勧めします。
🧠 Learnings used
Learnt from: FastDefence
Repo: NUTFes/SeeFT PR: 262
File: docker-compose.cd.yml:24-24
Timestamp: 2026-04-18T19:42:09.584Z
Learning: In the SeeFT repository, `api/env/seeft.env` is intentionally NOT tracked in git. It is a production secret environment file that is manually provisioned directly on the deployment server (`/home/deploy-user/SeeFT`). The `docker-compose.cd.yml` file references it via `env_file: ["./api/env/seeft.env"]` and this is by design — do not flag it as a missing or untracked file in future reviews.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/CD.yml:
- Around line 24-25: The docker compose commands (docker compose -f
docker-compose.cd.yml pull and docker compose -f docker-compose.cd.yml up -d)
rely on the HARBOR_REG compose variable but the workflow never provides it;
update the workflow step to supply HARBOR_REG explicitly (e.g., add HARBOR_REG
from secrets to the step env or prefix the docker compose commands with
HARBOR_REG=${{ secrets.HARBOR_REG }} so compose variable substitution can
resolve), and apply the same change for the alternate compose calls on lines
33–34.
- Around line 11-12: Remove the duplicate empty "SSH and Deploy" step and
consolidate into a single step that contains the SSH heredoc; ensure the heredoc
is properly opened and closed so all git commands (git fetch --unshallow, git
reset --hard origin/${{ github.ref }}, and any npm/build commands) run on the
remote host instead of the runner, and remove the extra unmatched EOF so there
is only one matching EOF pair for the SSH block.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdded a Docker-based CI/CD pipeline consisting of GitHub Actions workflows for automated building and deployment. The CI workflow builds and pushes Docker images to Harbor registry; the CD workflow deploys them to a production server via SSH using Docker Compose configuration. Changes
Sequence Diagram(s)sequenceDiagram
actor Developer
participant GitHub as GitHub<br/>(Actions)
participant Tailscale
participant Harbor as Harbor<br/>(Registry)
participant Runner as Self-hosted<br/>Runner
participant Server as Production<br/>Server
Developer->>GitHub: Push to main
GitHub->>GitHub: Trigger CI workflow
GitHub->>Tailscale: Connect with OAuth
Tailscale-->>GitHub: VPN established
GitHub->>Harbor: docker login
GitHub->>Harbor: Build & push API image
GitHub->>Harbor: Build & push Admin image
GitHub->>Harbor: Build & push Mobile image
GitHub->>GitHub: CI complete
GitHub->>GitHub: Trigger CD workflow
GitHub->>Runner: Execute CD job
Runner->>Server: SSH connect (deploy-user)
Runner->>Server: git fetch & reset origin/main
Server->>Harbor: docker login
Server->>Harbor: docker compose pull
Server->>Server: docker compose up -d
Server->>Server: docker image prune -f
Runner-->>GitHub: Deployment complete
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/CD.yml (1)
24-25:⚠️ Potential issue | 🟠 MajorSet
HARBOR_REGenvironment variable for docker compose (previously flagged).
docker-compose.cd.ymluses${HARBOR_REG}for image paths, but the workflow doesn't export this variable. While deployment may work if the server hasHARBOR_REGconfigured elsewhere (e.g., in a.envfile or system environment), making it explicit improves reliability.Suggested fix
echo '${{ secrets.HARBOR_PASS }}' | docker login '${{ secrets.HARBOR_REG }}' -u '${{ secrets.HARBOR_USERNAME }}' --password-stdin - docker compose -f docker-compose.cd.yml pull - docker compose -f docker-compose.cd.yml up -d + export HARBOR_REG='${{ secrets.HARBOR_REG }}' + docker compose -f docker-compose.cd.yml pull + docker compose -f docker-compose.cd.yml up -d,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/CD.yml around lines 24 - 25, The workflow runs "docker compose -f docker-compose.cd.yml pull" and "docker compose -f docker-compose.cd.yml up -d" but never sets the HARBOR_REG variable used by docker-compose.cd.yml; update the CD GitHub Actions job to export or set HARBOR_REG (e.g., add an env: HARBOR_REG: ${{ secrets.HARBOR_REG }} or a step that echoes "HARBOR_REG=..." to the environment) before the docker compose commands so ${HARBOR_REG} resolves during both the pull and up steps.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/CD.yml:
- Around line 24-25: The workflow runs "docker compose -f docker-compose.cd.yml
pull" and "docker compose -f docker-compose.cd.yml up -d" but never sets the
HARBOR_REG variable used by docker-compose.cd.yml; update the CD GitHub Actions
job to export or set HARBOR_REG (e.g., add an env: HARBOR_REG: ${{
secrets.HARBOR_REG }} or a step that echoes "HARBOR_REG=..." to the environment)
before the docker compose commands so ${HARBOR_REG} resolves during both the
pull and up steps.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2a36df18-6316-493e-bf79-d37bc2855a5c
📒 Files selected for processing (2)
.github/workflows/CD.yml.github/workflows/CI.yml
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.
対応Issue
resolve #261
概要
Docker Imageをgithub-runner側でビルドして、イメージレジストリにpushする。mainブランチにpushするとCICDが走るようにしています。
self-hosted-runnerがアプリがある仮想コンテナにsshして、Docker Imageのpullとコンテナ立ち上げを行う。
CD.ymlからpullしてきたイメージで、とりあえず動くようにしてあります。コンテナの設定に不備があれば教えてほしいです。
◾️Organization
HARBOR_PASS
HARBOR_REG
HARBOR_USERNAME
TAILSCALE_OAUTH_CLIENT_ID
TAILSCALE_OAUTH_CLINET_SECRET
◾️SeeFT Repository
CONTAINER_IP
SEEFT_MOBILE_ENV
画面スクリーンショット等
テスト項目
備考
Summary by CodeRabbit