[Chore] dev 서버용 CICD 설정 #45

ariimo · 2026-01-03T16:10:37Z

📌 관련 이슈

#44

✅ PR 체크리스트(최소요구조건)

✨ 작업 개요

develop 브랜치 push 시 자동 배포 파이프라인 추가
빌드/테스트 검증 후에만 배포 실행
환경변수/서버 정보는 Github Secret에 등록

🧹 작업 상세 내용

1. CI 단계

코드 체크아웃 후 Node.js 22, pnpm 9 환경 세팅
모든 패키지 의존성 설치
Lint, Test, Build를 자동 검증
테스트를 위한 임시 .env 파일 생성 (Secrets 활용)
Prisma Client 자동 생성

2. CD 단계

CI 성공 시에만 서버로 SSH 배포(appleboy/ssh-action 사용)
서버에서 develop 브랜치 동기화 및 .env.prod 생성
docker compose로 앱 재빌드 및 재실행
Prisma DB 스키마 자동 동기화

🔍 고민 지점

e2e test는 어떤 설정을 해줘야 할 것인가..

문제점
일단 e2e 테스트가 존재한다는 것을 보고 겁을 먹었으나...
테스트 및 빌드 단계에서 실제로 환경변수 파일 생성(.env)과 Prisma Client 생성(db:generate)이 꼭 필요한지 불분명
해결 과정
현재 작성된 테스트 코드들을 직접 확인해보니, 실제 DB 접속이나 환경변수, Prisma Client가 필요하지 않고 mock 객체만 사용하고 있더군요.
따라서 CI에서 해당 과정(임시 .env파일 생성, db:generate)은 현재로선 불필요하다는 결론에 도달했습니다.
실제 DB 접근 또는 Prisma Client import가 필요한 테스트가 추가되면 그때 반영하겠습니다.

GitHub Actions의 IP는 계속 바뀐다...!

문제점: CD(배포) 단계에서 GitHub Actions가 NCP 서버로 SSH 접속하려면, NCP 서버의 방화벽에서 22번 포트를 열어야합니다. 문제는 GitHub Actions 워크플로우는 매 실행마다 다른 IP에서 동작한다는 점...!
해결 과정: 일단, 임시로 전체 오픈 (0.0.0.0/0) 설정을 해두었습니다. ai는 배포 시에만 전체 오픈 (0.0.0.0/0) 설정을 해두라고 하는데,, 이거는 자동화의 의미가 아예 없어지는 방법이라고 생각합니다. 다행히, 조금 찾아보니 ncp 에서는 원격 ACG 설정이 가능하다고 하더군요!! 참고해서 보안까지 신경써 보도록 하겠습니당 (혹시, 다른 방법 아시는 분...알려주신다면 감사하겠습니다. )

- 현재 테스트를 살펴본 결과, mock만 사용한다는 것을 확인

qjatjr29

👍

qjatjr29 · 2026-01-04T01:18:45Z

.github/workflows/deploy-dev.yml

+      - name: Install Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 22


현재 매번 pnpm install을 해주는 것 같아요!!
Turborepo로 캐시된 것을 이용해볼 수 있을 것 같아요!! (사실 저도 안해봄)

Suggested change

- name: Install Node.js

uses: actions/setup-node@v3

with:

node-version: 22

- name: Install Node.js

uses: actions/setup-node@v3

with:

node-version: 22

cache: 'pnpm'

와ㅏ
GitHub Actions은 매번 새로운 환경에서 실행하니깐, 모든 의존성을 새로 다운로드하게 되는 거군요...!
반영해서 캐시 처리해두겠숩니당

qjatjr29 · 2026-01-04T01:26:02Z

.github/workflows/deploy-dev.yml

+    steps:
+      - name: Deploy to Server via SSH
+        uses: appleboy/ssh-action@master
+        with:
+          host: ${{ secrets.DEV_HOST }}
+          username: ${{ secrets.DEV_USERNAME }}
+          password: ${{ secrets.DEV_PASSWORD }}
+          script: |
+            cd ~/projects/web06-locus
+            git fetch origin develop
+            git checkout -f develop
+            git pull origin develop
+            echo "${{ secrets.DEV_ENV_PROD }}" > .env.prod
+            docker compose down
+            docker compose up -d --build
+            docker compose exec -T locus-api pnpm --filter @locus/api run db:push


deploy때 서버(NCP)에 접속하여 그 안에서 직접 docker compose up --build를 실행하는 것 같아요
( 빌드할 때 서버 CPU와 메모리를 많이 사용할 수도 있다고 ..들음)

Docker Hub나 NCP의 Container Registry같은 것을 활용해보는 방식도 좋을거 같습니다!!

GitHub Actions에서 이미지를 빌드 + 푸시하고 서버에서는 pull만 받는 방식
만약 사용한다면 NCP거 써보는 것도 좋을거 같습니다!! dockerhub보다는 내부 네트워크를 사용해서 더 빠르지 않으려나..?

Suggested change

steps:

- name: Deploy to Server via SSH

uses: appleboy/ssh-action@master

with:

host: ${{ secrets.DEV_HOST }}

username: ${{ secrets.DEV_USERNAME }}

password: ${{ secrets.DEV_PASSWORD }}

script: |

cd ~/projects/web06-locus

git fetch origin develop

git checkout -f develop

git pull origin develop

echo "${{ secrets.DEV_ENV_PROD }}" > .env.prod

docker compose down

docker compose up -d --build

docker compose exec -T locus-api pnpm --filter @locus/api run db:push

steps:

- name: Login to NCP Registry

# NCP Container Registry 로그인 및 이미지 Push 단계 추가 필요

- name: Deploy to Server via SSH

uses: appleboy/ssh-action@master

with:

host: ${{ secrets.DEV_HOST }}

username: ${{ secrets.DEV_USERNAME }}

password: ${{ secrets.DEV_PASSWORD }}

script: |

docker pull <NCP_REGISTRY_URL>/api:latest

docker compose up -d

...

도커 빌드 중 자원 소모는 고려를 못 했네요. 조금 찾아보니, 자원 소모뿐만 아니라

빌드와 운영의 분리

무중단 배포의 용이성
등등 여러 이유로 배포 환경과 빌드 환경을 분리하는 게 좋다고 하는군요!

Container Registry 서비스 조금 찾아봤는데, NCP 내부 네트워크로 주고 받을 때만 요금이 발생한대요! 말씀해 주신 방법대로 GitHub Actions에서 이미지를 빌드 + 푸시하고 서버에서는 pull만 받는 방식으로 구현해보겠습니다!

qjatjr29 · 2026-01-04T01:31:25Z

.github/workflows/deploy-dev.yml

+            git pull origin develop
+            echo "${{ secrets.DEV_ENV_PROD }}" > .env.prod
+            docker compose down
+            docker compose up -d --build


docker compose up -d --build는 전체 서비스를 다시 빌드하는 것으로 아는데
Turborepo의 --filter 옵션을 활용하여 변경된 패키지(react or nestjs)만 빌드하고 배포할 수 있나요??? (잘 모름 ㅜ)

네!
꼭 --filter 옵션을 직접 쓰지 않아도, Turborepo가 내부적으로 해시값을 비교해서 변경된 패키지만 빌드한다고 해요...! docker compose up -d 명령어는 이미지가 바뀐 컨테이너만 교체하니, 이렇게 하면 그루가 말씀해주신 방향성으로 구현할 수 있을 것 같아요!
좋은 피드백 감사합니다!

qjatjr29 · 2026-01-04T01:32:03Z

.github/workflows/deploy-dev.yml

+            echo "${{ secrets.DEV_ENV_PROD }}" > .env.prod
+            docker compose down
+            docker compose up -d --build
+            docker compose exec -T locus-api pnpm --filter @locus/api run db:push


db:push는 스키마를 강제로 맞추는 것이라서 데이터 유실이 있을 수 있는데 추후 운영 환경에서는 db:migrate를 사용하나요~?

아직은 erd 가 확정되지 않은 상황이니, 우선 db:push로 남겨두고 추후 운영 환경에서는 db:migrate로 변경 사항 남겨가며 운영하는 게 좋을 것 같아요!!

qjatjr29 · 2026-01-04T01:38:19Z

GitHub Actions의 IP는 계속 바뀐다...!

문제점: CD(배포) 단계에서 GitHub Actions가 NCP 서버로 SSH 접속하려면, NCP 서버의 방화벽에서 22번 포트를 열어야합니다. 문제는 GitHub Actions 워크플로우는 매 실행마다 다른 IP에서 동작한다는 점...!

해결 과정: 일단, 임시로 전체 오픈 (0.0.0.0/0) 설정을 해두었습니다. ai는 배포 시에만 전체 오픈 (0.0.0.0/0) 설정을 해두라고 하는데,, 이거는 자동화의 의미가 아예 없어지는 방법이라고 생각합니다. 다행히, 조금 찾아보니 ncp 에서는 원격 ACG 설정이 가능하다고 하더군요!! 참고해서 보안까지 신경써 보도록 하겠습니당 (혹시, 다른 방법 아시는 분...알려주신다면 감사하겠습니다. )

말씀 주신 것처럼 NCP에서 NCP CLI 같은거 이용해서 배포 과정에서 현재 실행 중인 GitHub Actions의 IP를 알아내서 NCP의 ACG에 등록했다가 배포가 끝나면 자동으로 삭제하는 방식 같은거 사용해보는 것도 재밌어보입니다..!

저도 이전까지는 ssh 공격 같은거 잘 신경 안썼는데 지난 스프린트에서 한번 브루트포스 공격 받아봐서... ssh 포트로 22를 사용하지 않는 것도 좋아보여요(직접 설정한 후 Github actions secrets 등으로 관리, 22는 너무 예측 가능한 포트번호라서?!?)
보안까지 신경써주시다니 감사합니다! 🙇

mindaaaa

역시 인프라는 고려할 게 정말 많군요...!
주말에 시간 내서 다시 한번 정독해봐야겠습니다!!

CI/CD 구축이 어느 정도 안정되면
저희 팀 블로그에 한 번 정리해주실 수 있을까요!?🙇‍♀️

mindaaaa · 2026-01-05T00:37:55Z

.github/workflows/deploy-dev.yml

+            git fetch origin develop
+            git checkout -f develop
+            git pull origin develop
+            echo "${{ secrets.DEV_ENV_PROD }}" > .env.prod


이 env는 저희 리포지토리 env는 아닌거같은데, github actions에서 설정하는 env 같은건가요?

GitHub Actions에서 env를 따로 관리하다가,
서버에 주입해주는 느낌...? 인건가요!?

github actions secrets 에 .env 파일 전체를 넣는 형식으로 구성하신거 같아요!@

네! 맞아요. 시크릿으로 ncp 개발 서버용 env 파일 전체를 넣어뒀습니다.

ariimo · 2026-01-05T14:10:49Z

GitHub Actions의 IP는 계속 바뀐다...!
문제점: CD(배포) 단계에서 GitHub Actions가 NCP 서버로 SSH 접속하려면, NCP 서버의 방화벽에서 22번 포트를 열어야합니다. 문제는 GitHub Actions 워크플로우는 매 실행마다 다른 IP에서 동작한다는 점...!
해결 과정: 일단, 임시로 전체 오픈 (0.0.0.0/0) 설정을 해두었습니다. ai는 배포 시에만 전체 오픈 (0.0.0.0/0) 설정을 해두라고 하는데,, 이거는 자동화의 의미가 아예 없어지는 방법이라고 생각합니다. 다행히, 조금 찾아보니 ncp 에서는 원격 ACG 설정이 가능하다고 하더군요!! 참고해서 보안까지 신경써 보도록 하겠습니당 (혹시, 다른 방법 아시는 분...알려주신다면 감사하겠습니다. )

말씀 주신 것처럼 NCP에서 NCP CLI 같은거 이용해서 배포 과정에서 현재 실행 중인 GitHub Actions의 IP를 알아내서 NCP의 ACG에 등록했다가 배포가 끝나면 자동으로 삭제하는 방식 같은거 사용해보는 것도 재밌어보입니다..!

저도 이전까지는 ssh 공격 같은거 잘 신경 안썼는데 지난 스프린트에서 한번 브루트포스 공격 받아봐서... ssh 포트로 22를 사용하지 않는 것도 좋아보여요(직접 설정한 후 Github actions secrets 등으로 관리, 22는 너무 예측 가능한 포트번호라서?!?) 보안까지 신경써주시다니 감사합니다! 🙇

우선, 늦은 답변 죄송합니다. 제가 인프라 경험이 거의 없어서 이래 저래 찾아보느라, 답변이 늦어졌어요. 🥲
(이렇게 찾아보며 정리한 부분은 노션에 넣어두겠습니다.)

그리고 "GitHub Actions의 IP를 알아내서 NCP의 ACG에 등록했다가 배포가 끝나면 자동으로 삭제하는 방식" 이 제가 구글링으로 찾아낸 방법이었습니다...!! 말씀해 주신 방향성 잘 참고해서 추후 적용해보도록 하겠습니다. (피해자셨군요....ㅎㅎ)

ariimo · 2026-01-05T14:14:31Z

역시 인프라는 고려할 게 정말 많군요...! 주말에 시간 내서 다시 한번 정독해봐야겠습니다!!

CI/CD 구축이 어느 정도 안정되면 저희 팀 블로그에 한 번 정리해주실 수 있을까요!?🙇‍♀️

이미 노션에 지금까지의 과정을 나름...! 꼼꼼히 정리해서 올려두었습니다. 이걸 개발 블로그에 넣으면 될 것 같은데, 혹시 노션 to 티스토리 빠른 변환 방법을 알고 있으신가요...? (저번에 시도해봤는데, 복사 붙여넣기로는 이미지가... 안 넘어가더군요ㅠㅠㅜㅠ)

qjatjr29 · 2026-01-05T14:23:28Z

이미 노션에 지금까지의 과정을 나름...! 꼼꼼히 정리해서 올려두었습니다. 이걸 개발 블로그에 넣으면 될 것 같은데, 혹시 노션 to 티스토리 빠른 변환 방법을 알고 있으신가요...? (저번에 시도해봤는데, 복사 붙여넣기로는 이미지가... 안 넘어가더군요ㅠㅠㅜㅠ)

전 미리보기 보면서 하나하나 고쳐줬는데
이거 진짜 하나 변환해주는거 개발해보고 싶네요 진짜 해보려고요

ariimo · 2026-01-05T14:25:28Z

이미 노션에 지금까지의 과정을 나름...! 꼼꼼히 정리해서 올려두었습니다. 이걸 개발 블로그에 넣으면 될 것 같은데, 혹시 노션 to 티스토리 빠른 변환 방법을 알고 있으신가요...? (저번에 시도해봤는데, 복사 붙여넣기로는 이미지가... 안 넘어가더군요ㅠㅠㅜㅠ)

전 미리보기 보면서 하나하나 고쳐줬는데 이거 진짜 하나 변환해주는거 개발해보고 싶네요 진짜 해보려고요

제가 만들거예요
ㅋㅋㅋㅋㅋ

qjatjr29 · 2026-01-05T14:26:40Z

제가 만들거예요 ㅋㅋㅋㅋㅋ

서로 피드백 해주죠!

mindaaaa · 2026-01-06T04:38:06Z

두 분이 만들어주시면 제가 잘 사용하겠습니다

- cache: 'pnpm' 옵션 추가 - Turbo 캐시사용 - NCR 사용

vaaast-lake

고생 많았어요 👍

pnpm/action-setup@v2 관련 이슈가 좀 치명적이라 생각해서 Request changes 걸어놨어요.

그 외에는 각 액션을 하위 버전으로 이용하는 이유가 필요할 것 같아요.

GitHub Actions의 IP는 계속 바뀐다...!

이 부분 관련해서는... self-hosted runner로 굴려보는 것도 괜찮을 것 같네요. 러너용 VPC를 따로 파서 서비스 서버에 접근하는 것도 방법이 될 수 있어보여요. 해봤는데 생각보다 간단합니다.

다만 러너의 경우 서버 사용자가 사용하는 path를 사용하지 않기 때문에, 특정 사용자로 원하는 패키지를 실행시키는 건 또 다른 작업이 필요하다는 점... 이있지만, 이 부분은 도커를 사용한다면 또는 다른 서버에 ssh로 사용자로서 로그인 한다면 큰 문제 아니긴 해요.

그외, ai가 제안해주는 방식(웹 훅 걸어서 CI로 도커 레지스트리에 등록 후 서버에 푸시하고 서버가 스크립트 돌리고....)들은 머리도 복잡하고 손이 많이 가는 방식이긴 하네요.

"러너용 VPC" 또는 "서비스 VPC에 러너 설치"가 베스트일 것 같습니다.

vaaast-lake · 2026-01-07T01:23:11Z

.github/workflows/deploy-dev.yml

+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Install pnpm
+        uses: pnpm/action-setup@v2
+        with:
+          version: 9
+
+      - name: Install Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 22


아래 각 액션 버전이 최신으로 알고있는데, 하위 버전을 사용한 이유가 있을까요?

Suggested change

- name: Checkout code

uses: actions/checkout@v3

- name: Install pnpm

uses: pnpm/action-setup@v2

with:

version: 9

- name: Install Node.js

uses: actions/setup-node@v3

with:

node-version: 22

- name: Checkout code

uses: actions/checkout@v5

- name: Install pnpm

uses: pnpm/action-setup@v4

with:

version: 9

- name: Install Node.js

uses: actions/setup-node@v6

with:

node-version: 22

node version 22를 사용하면 최신 버전을 사용하는게 더 좋아보이네요!

.github/workflows/deploy-dev.yml

vaaast-lake · 2026-01-07T01:37:45Z

.github/workflows/deploy-dev.yml

+        uses: actions/checkout@v3
+
+      - name: Install pnpm
+        uses: pnpm/action-setup@v2


pnpm/action-setup@v2는 하위 노드 버전에서 동작하지 않는 이슈가 있는 것 같아요. pnpm/action-setup 레포에서도 v2에서 v4로 업그레이드하라고 경고문을 최상단에 넣어놓긴 했네요.

node를 22버전(LTS)을 사용하기 때문에 실패했을 확률이 높아요.

헉.. 확인해보니, 이제는 아예 v2를 중단했군요. 아주 큰 일 날 뻔했네요ㅠㅜ
감사합니다!!

vaaast-lake · 2026-01-07T01:48:47Z

.github/workflows/deploy-dev.yml

+          cache: 'pnpm'
+
+      - name: Turbo Cache
+        uses: actions/cache@v3


actions/cache의 경우도 4버전이 최신이네요

Suggested change

uses: actions/cache@v3

uses: actions/cache@v4

vaaast-lake · 2026-01-07T01:53:41Z

.github/workflows/deploy-dev.yml

+        run: pnpm turbo run build test lint --cache-dir=".turbo"
+
+      - name: Login to NCR
+        uses: docker/login-action@v2


해당 부분도 v3이 최신이긴 합니다.

Suggested change

uses: docker/login-action@v2

uses: docker/login-action@v3

vaaast-lake · 2026-01-07T01:57:21Z

.github/workflows/deploy-dev.yml

+      - name: Build and Push API Image
+        run: |
+          docker build -t ${{ secrets.DEV_REGISTRY }}/locus-api:latest -f apps/api/Dockerfile .
+          docker push ${{ secrets.DEV_REGISTRY }}/locus-api:latest
+
+      - name: Build and Push Nginx Image
+        run: |
+          docker build -t ${{ secrets.DEV_REGISTRY }}/locus-nginx:latest -f nginx/Dockerfile .
+          docker push ${{ secrets.DEV_REGISTRY }}/locus-nginx:latest


이 부분은 그냥 제안입니다.

# 3. Docker 이미지 빌드 및 푸시 - name: Build and push Docker image uses: docker/build-push-action@v5 with: context: . file: ./be/Dockerfile push: true tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest

앞서 GHCR을 이용했다면, docker/build-push-action@v5으로 간편하게 레지스트리에 이미지를 올릴 수 있습니다.

또, 이미지 올릴 때, 롤백을 고려한다면 태그를 2개로 (latest, v00) 관리해볼 수도 있겠네요.

이 부분 저도 문서에 코멘트 남기긴했는데 이미지 태깅을 해보는 것도 재밌을거 같아요~!@

추가로 Github 릴리스 태그도 해보면 좋지 않을까!

확인해보니, docker/build-push-action@v5 가 특정 레지스트리에 종속되지 않더군요!
docker/build-push-action 과 태그 전략까지 모두 반영하겠습니당

- 각종 버전 최신화 - docker/build-push-action@v5 사용

ariimo · 2026-01-07T08:47:07Z

고생 많았어요 👍

pnpm/action-setup@v2 관련 이슈가 좀 치명적이라 생각해서 Request changes 걸어놨어요.

그 외에는 각 액션을 하위 버전으로 이용하는 이유가 필요할 것 같아요.

GitHub Actions의 IP는 계속 바뀐다...!

이 부분 관련해서는... self-hosted runner로 굴려보는 것도 괜찮을 것 같네요. 러너용 VPC를 따로 파서 서비스 서버에 접근하는 것도 방법이 될 수 있어보여요. 해봤는데 생각보다 간단합니다.

다만 러너의 경우 서버 사용자가 사용하는 path를 사용하지 않기 때문에, 특정 사용자로 원하는 패키지를 실행시키는 건 또 다른 작업이 필요하다는 점... 이있지만, 이 부분은 도커를 사용한다면 또는 다른 서버에 ssh로 사용자로서 로그인 한다면 큰 문제 아니긴 해요.

그외, ai가 제안해주는 방식(웹 훅 걸어서 CI로 도커 레지스트리에 등록 후 서버에 푸시하고 서버가 스크립트 돌리고....)들은 머리도 복잡하고 손이 많이 가는 방식이긴 하네요.

"러너용 VPC" 또는 "서비스 VPC에 러너 설치"가 베스트일 것 같습니다.

아..... 참고한 코드에서 버전 확인을 못 하고 바로바로 가져다 썼었네요... 다음부터는 버전까지 잘 확인하는 멋진 개발자가 되겠습니다..!!
(피드백 주신 부분은 학습 정리와 함께 정리해서 노션에 올려두겠습니다!!)

말씀 주신 self-hosted runner 도 좋은 방법이 될 수 있겠군요!! 이 부분은 다양한 방법을 고려해 볼 수 있을 것 같아서 추후 참고해서 적용하도록 하겠숩니당. 상세한 코드리뷰 감사합니다.

vaaast-lake

애타는 마음 가라앉길 바랍니다 😂

ariimo · 2026-01-07T09:36:52Z

애타는 마음 가라앉길 바랍니다 😂

진정 완료!! 😇
감사합니다아ㅏ

merge

ariimo added 2 commits January 4, 2026 00:27

chore: dev 서버용 cicd 설정

92b36f9

refac: Prisma client 생성 과정 제거

d7779c9

- 현재 테스트를 살펴본 결과, mock만 사용한다는 것을 확인

ariimo self-assigned this Jan 3, 2026

ariimo added the infra 배포, CI/CD, 인프라 설정 관련 작업 label Jan 3, 2026

ariimo linked an issue Jan 3, 2026 that may be closed by this pull request

[Chore] 개발 서버 CI/CD #44

Closed

qjatjr29 approved these changes Jan 4, 2026

View reviewed changes

mindaaaa approved these changes Jan 5, 2026

View reviewed changes

feat: CICD 수정

4283e4e

- cache: 'pnpm' 옵션 추가 - Turbo 캐시사용 - NCR 사용

vaaast-lake requested changes Jan 7, 2026

View reviewed changes

feat: deploy-dev 파일 버전 업데이트 및 캐시 설정 추가

fb8f1ff

- 각종 버전 최신화 - docker/build-push-action@v5 사용

vaaast-lake approved these changes Jan 7, 2026

View reviewed changes

Merge branch 'develop' into chore/#44-dev-cicd

d365bab

merge

ariimo merged commit 0aa8346 into develop Jan 7, 2026

[Chore] dev 서버용 CICD 설정 #45

[Chore] dev 서버용 CICD 설정 #45

Uh oh!

Conversation

ariimo commented Jan 3, 2026

📌 관련 이슈

✅ PR 체크리스트(최소요구조건)

✨ 작업 개요

🧹 작업 상세 내용

1. CI 단계

2. CD 단계

🔍 고민 지점

Uh oh!

qjatjr29 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

qjatjr29 commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mindaaaa left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ariimo commented Jan 5, 2026

Uh oh!

ariimo commented Jan 5, 2026

Uh oh!

qjatjr29 commented Jan 5, 2026

Uh oh!

ariimo commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qjatjr29 commented Jan 5, 2026

Uh oh!

mindaaaa commented Jan 6, 2026

Uh oh!

vaaast-lake left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

qjatjr29 commented Jan 4, 2026 •

edited

Loading

mindaaaa left a comment •

edited

Loading

ariimo commented Jan 5, 2026 •

edited

Loading

vaaast-lake left a comment •

edited

Loading