Logpush Provision Failure Analysis

GitHub Actions 로그 기준. 코드 수정 없이 원인 분석만 기술.

---

1. 로그에서 보이는 에러

📤 Provisioning Logpush (R2 + Job)...
chmod: cannot access '/home/runner/work/newsfork-seeds/newsfork-seeds/.github/scripts/lib/provision-logpush.sh': No such file or directory
##[error]Process completed with exit code 1.

• 실제 시도한 경로: .github/scripts/lib/provision-logpush.sh
• 실제 파일 위치: .github/scripts/steps/provision-logpush.sh
• 즉, lib/ 아래에서 찾고 있어서 “No such file or directory”가 발생한 상태다.

---

2. 원인: SCRIPT_DIR 덮어쓰기

2.1 provision-resources.sh의 흐름

1. 맨 위
   SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
   → 이 스크립트는 .github/scripts/steps/provision-resources.sh 이므로
   SCRIPT_DIR = .github/scripts/steps (steps 디렉터리).

2. 이어서
   source "$SCRIPT_DIR/../lib/cloudflare-resources.sh"
   → cloudflare-resources.sh를 같은 셸에서 실행.

3. cloudflare-resources.sh 안에서
   같은 변수 이름으로 다시 설정함:

   SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

   • source로 불렸을 때 BASH_SOURCE[0]는 지금 실행 중인 스크립트인
     cloudflare-resources.sh 경로를 가리킴.
   • 따라서 여기서의 SCRIPT_DIR = cloudflare-resources.sh가 있는 디렉터리
     = .github/scripts/lib.

4. source가 끝난 뒤
   provision-resources.sh로 돌아와도, 변수는 한 셸을 공유하므로
   SCRIPT_DIR는 lib 쪽으로 덮어씌워진 상태가 유지됨.

5. Step 4 (Logpush) 에서
   chmod +x "$SCRIPT_DIR/provision-logpush.sh"
"$SCRIPT_DIR/provision-logpush.sh"
   → 이때의 SCRIPT_DIR = .github/scripts/lib
   → .github/scripts/lib/provision-logpush.sh 를 찾게 되고,
   실제 파일은 steps/provision-logpush.sh 에만 있으므로 “No such file or directory”.

정리하면, Logpush 단계에서 사용하는 SCRIPT_DIR가 steps가 아니라 lib로 바뀐 것이 직접 원인이다.

---

3. 왜 SCRIPT_DIR이 바뀌는가

구분	설명
Bash source	다른 스크립트를 현재 셸에서 그대로 실행. 변수·함수 모두 같은 환경 공유.
의도	provision-resources.sh 입장에서는 “steps 디렉터리”를 담아두려고 SCRIPT_DIR을 썼음.
실제	lib/cloudflare-resources.sh가 자기 위치를 알기 위해 같은 이름 SCRIPT_DIR을 설정하면서, 호출자(steps)가 넣어둔 값을 덮어씀.

그래서 파일 경로는 잘못된 것이 아니라, “steps 디렉터리”를 가리키는 변수가 나중에 “lib 디렉터리”로 덮어씌워진 것이 문제다.

---

4. 수정 방향 (구현은 하지 않음)

• Step 4에서 쓸 경로는 “steps 디렉터리”를 가리켜야 함.
• 따라서 다음 중 하나로 정리하면 됨.

1. steps 경로를 별도 변수로 보존

   • provision-resources.sh 상단에서, source 하기 전에
     예: STEPS_DIR="$SCRIPT_DIR" 같은 변수에 steps 경로를 저장해 두고,
     Step 4에서는 $STEPS_DIR/provision-logpush.sh 를 사용.

2. Step 4에서 상대 경로로 고정

   • SCRIPT_DIR에 의존하지 않고,
     예: "$(dirname "${BASH_SOURCE[0]}")/provision-logpush.sh" 처럼
     “이 스크립트(provision-resources.sh)와 같은 디렉터리”를 기준으로 경로를 만든다.
   • 단, 이때는 provision-resources.sh를 어디서 실행하느냐(현재 디렉터리)에 따라 동작이 달라질 수 있으므로, BASH_SOURCE[0]를 쓰는 방식이 더 안전하다.

3. lib 스크립트 쪽에서 변수 이름 분리

   • cloudflare-resources.sh에서 자기 디렉터리용 변수 이름을
     예: LIB_DIR 등으로 바꾸어, 호출자의 SCRIPT_DIR를 덮어쓰지 않게 함.
   • 이렇게 하면 다른 step에서도 SCRIPT_DIR이 steps로 유지되므로, 1번과 함께 쓰면 일관성이 좋다.

---

5. 요약

항목	내용
증상	chmod / 실행 시 .github/scripts/lib/provision-logpush.sh 를 찾다가 “No such file or directory”로 실패.
직접 원인	Step 4에서 사용한 SCRIPT_DIR이 steps가 아니라 lib를 가리키고 있음.
근본 원인	source된 lib/cloudflare-resources.sh가 같은 셸에서 SCRIPT_DIR을 다시 설정하면서, provision-resources.sh가 steps용으로 써 두었던 값을 덮어씀.
수정 포인트	steps 디렉터리 경로를 덮어쓰이지 않게 보존하거나, Step 4에서 “steps 디렉터리”를 명시적으로 사용하도록 변경.

이 문서는 원인 분석만 담고 있으며, 실제 코드 변경은 하지 않았다.