직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 GitHubActions6 GitHub pull_request_target 기본 차단 예고: 12월 일정과 11월 시험 구간 확인 GitHub의 pull_request_target 기본 차단은 2026년 12월 2일 시행 예고와 11월의 시험 차단 구간을 나누어 읽어야 합니다. 11월 2일 공지는 이전에 잡았던 시행 날짜를 변경한 안내입니다. 제목만 보고 지금 모든 저장소의 워크플로가 막혔다고 판단하지 마세요.이번 글은 2026년 11월 3일 확인한 공식 자료를 기준으로 현재 평가 상태, 시험 구간, 향후 예고를 구분합니다. 실제 저장소의 정책이나 실패 기록을 조회하고 변경한 작업은 없으며, 자신의 계정에 무엇이 적용됐는지는 별도 확인이 필요합니다.11월 2일 공지에서 어떤 날짜가 바뀌었나요?GitHub는 기본 보호의 강제 적용 예고를 이전 11월 2일에서 12월 2일로 옮겼다고 안내합니다. 대상은 github.com의 Free·T.. 2026. 11. 4. GitHub Actions lockfiles 정식 제공: 태그와 실행 커밋을 나누어 보기 GitHub Actions의 workflow lockfiles가 2026년 10월 28일 정식 제공으로 전환됐습니다. 워크플로에 읽기 쉬운 태그·브랜치 참조를 두면서 실행할 액션의 커밋을 따로 고정하는 기능입니다. 도입을 검토한다면 고정할 대상, 업데이트를 검토할 사람, 고정 범위 밖의 입력을 나누어 보세요.이번 글은 공식 발표와 문서를 읽고 도입 판단을 돕는 안내입니다. 확장 도구를 설치하거나 잠금 파일을 생성하고 CI를 실행한 시험 결과는 없습니다. 아래의 검토표와 가상 변경 요청은 팀이 질문을 정리하도록 직접 구성한 예시입니다.이번 정식 제공에서 무엇이 달라졌나요?GitHub의 10월 28일 공지는 Enterprise Cloud, 데이터 레지던시를 사용하는 Enterprise Cloud, Team,.. 2026. 11. 2. GitHub Actions npm 캐시 복원 후 모듈이 없을 때: npm ci·lockfile·작업 경로 점검 setup-node의 npm 캐시가 복원돼도 node_modules가 설치됐다는 뜻은 아닙니다. 이 캐시는 패키지 관리자의 다운로드 데이터를 재사용하는 기능이므로 실제 프로젝트 폴더에서 npm ci 같은 설치 단계가 필요합니다. 캐시가 맞았다는 이유로 설치를 건너뛰었다면 먼저 그 조건을 제거하고, lockfile 위치와 명령 실행 경로를 맞추세요.자료 확인 기준일은 2026년 10월 13일입니다. 아래 예시는 공식 문서를 바탕으로 작성한 설계·점검 예이며, 이 글에서 실제 계정이나 서버에 실행한 시험 결과는 아닙니다.원인: 다운로드 캐시와 설치된 의존성 폴더를 혼동합니다setup-node 문서는 전역 패키지 데이터를 캐시하며 node_modules를 캐시하지 않는다고 설명합니다. 다운로드 캐시가 있다는 .. 2026. 10. 14. GitHub Actions SSH Permission denied (publickey) 해결: 배포 서버와 저장소 인증 구분 GitHub Actions에서 Permission denied (publickey)가 나오면 먼저 실패한 접속의 목적지와 사용자를 확인하세요. 러너가 배포 서버에 들어가지 못한 경우와, 서버에 들어간 다음 git fetch가 GitHub에서 거부된 경우는 공개키 등록 위치가 다릅니다. 한 키를 여러 위치에 다시 붙여 넣는 방식보다 연결을 두 단계로 나누는 것이 먼저입니다.이 글은 OpenSSH 기반 Linux 배포 서버와 SSH GitHub 인증을 사용하는 흐름을 다룹니다. 서드파티 배포 Action마다 입력값 형식이 다르므로 해당 Action의 고정 버전 문서도 함께 확인해야 합니다. 문서 확인 기준일은 2026-10-10입니다. 실제 러너·서버에 접속하거나 개인키를 읽지 않았으며 명령은 진단 예시입니.. 2026. 10. 12. GitHub Actions와 GitLab CI 비교: 기업용 CI/CD 비용·러너·권한 선택 기준 팀의 CI/CD를 고를 때 “GitHub Actions와 GitLab CI 중 어느 쪽이 더 저렴한가”부터 묻기 쉽습니다. 하지만 저장소 위치, 러너 운영 방식, 승인 절차, 실행 시간과 산출물 보관량이 다르면 같은 분당 가격을 비교해도 결론이 틀립니다. 이미 GitHub에 코드를 두고 간단한 자동화를 시작한다면 Actions가 자연스러운 출발점입니다. GitLab의 저장소·보안·배포 기능을 함께 운영하거나 자체 러너 정책이 중요한 팀은 GitLab CI/CD를 같은 조건에서 시험해 보세요.1. 먼저 저장소와 실행 환경을 고정하세요GitHub Actions는 GitHub 저장소의 이벤트와 워크플로 파일을 중심으로 실행됩니다. GitLab CI/CD는 GitLab 프로젝트의 파이프라인과 러너를 중심으로 구.. 2026. 9. 29. GitHub Actions 403 해결: GITHUB_TOKEN 권한·포크 PR·OIDC 점검 그림: GitHub Actions 403은 실행 이벤트, 토큰 권한, 외부 클라우드 역할을 차례로 분리해 점검합니다.GitHub Actions에서 Resource not accessible by integration 또는 HTTP 403이 나오면 토큰 문자열을 새로 만드는 것부터 시작하기 쉽습니다. 그러나 대부분은 어떤 이벤트로 실행됐는지, 어떤 권한이 부여됐는지, 어느 API가 거부했는지를 구분해야 해결됩니다. 특히 포크 PR과 OIDC 배포는 일반 push와 권한 조건이 다릅니다.1. 먼저 실패한 API와 실행 이벤트를 찾는다로그에서 실패한 단계와 요청 대상이 GitHub API인지, 패키지 레지스트리인지, AWS 같은 외부 서비스인지 확인하세요. 이어 워크플로의 on: 이벤트, 저장소·조직의 Act.. 2026. 9. 26. 이전 1 다음
