CI/CD 도구
workflow YAML을 붙여넣으면 포맷팅되고, job/step 트리를 따라가며 matrix나 cron 초안을 만든 뒤 본문에 반영할 수 있습니다.
모든 처리는 브라우저 안에서만 이루어지며 GitHub나 서버로 전송되지 않습니다.
검증 대기 중…
workflow YAML의 문제는 대개 push하고 나서야 드러납니다 — runs-on을 빠뜨린 job, 실제로는 존재하지 않는 permissions 값, 조용히 한 번도 실행되지 않은 schedule 같은 것들입니다. 이 GitHub Actions 워크플로우 검증 도구는 단순한 YAML 문법 오류가 아니라 CI가 실제로 의존하는 구조를 로컬에서 검사해서, 이런 실수를 실행 전에 잡아냅니다.
job이 여러 개인 긴 workflow를 수정하면서 깨진 부분으로 바로 이동하고 싶을 때, OS와 버전 조합으로 build matrix를 구성할 때, 여러 step에 걸친 env·secrets·vars 참조를 정리하고 싶을 때, on.schedule에 cron 표현식을 작성하면서 GitHub Actions가 실제로 허용하는 범위가 궁금할 때 쓰기 좋습니다.
범용 YAML 린터, matrix 생성기, GitHub Actions를 전혀 모르는 cron 도구를 따로따로 오갈 필요가 없습니다.
workflow를 붙여넣으면 YAML이 포맷팅되고, job id와 step id의 명명 규칙, 각 job이 runs-on 또는 uses 중 하나를 반드시 갖는지, permissions 값이 실제 열거형과 맞는지(id-token은 write 또는 none만 가능), branches와 branches-ignore가 동시에 쓰이는 것 같은 상호 배타 조건까지 검사됩니다. 이어서 클릭 가능한 job/step 트리가 만들어져 항목을 선택하면 에디터가 해당 줄로 바로 이동합니다.
참조 목록은 발견된 모든 ${{ env.X }}, ${{ secrets.X }}, ${{ vars.X }}, ${{ github.X }} 표현식을 소속 job과 step과 함께 나열합니다. 공식 문서에 명시된 세 가지 실제 오류 지점도 개별적으로 표시됩니다: env는 step의 id나 uses에 쓸 수 없고, secrets는 if: 조건에 직접 쓸 수 없으며, github는 uses:에 쓸 수 없습니다.
cron 패널은 표준 5필드 표현식을 만들면서 GitHub가 schedule 트리거에 대해 문서화한 제한을 그대로 적용합니다: 최소 5분 간격, 기본 UTC와 선택적인 IANA 타임존, @daily 같은 별칭 미지원, 공개 저장소가 60일간 활동이 없으면 자동 비활성화되는 것까지요.
툴바에 보이는 것보다 뒤에서 훨씬 많은 일이 자동으로 일어납니다.
에디터에서 복사한 workflow YAML을 붙여넣거나, 내장 예제를 불러오세요. 예제에는 schedule 트리거, strategy.matrix가 있는 job, env/secrets/github 참조가 모두 포함되어 있어 다섯 가지 기능을 한 번에 볼 수 있습니다. 자동 검증은 기본으로 켜져 있고 입력을 멈춘 뒤 350ms 후 다시 실행되며, 아무것도 업로드되지 않습니다.
matrix 변수 표나 cron 필드를 아무리 수정해도 그 자체로는 workflow가 바뀌지 않고 미리보기만 갱신됩니다. "삽입"을 눌러야 strategy.matrix나 on.schedule에 실제로 기록되며, 누르기 전에도 초안 조각만 따로 복사할 수 있습니다.
env/secrets/vars/github 참조 목록이 표시하는 것은 범용 린터의 추측이 아니라 GitHub Actions가 실제로 거부한다고 문서화된 위치입니다. 자동 검증을 끈 상태라면 Ctrl/Cmd+Enter로 다시 검증할 수 있습니다. 검증 후 계속 편집하면 다시 검증할 때까지 복사와 다운로드가 비활성화되어, 오래된 결과를 내보내는 일이 없습니다.
다섯 가지 기능이 각각 다른 탭이 아니라 한 화면 안에서 서로 연결됩니다.
2칸 또는 4칸으로 일관된 들여쓰기로 workflow를 다시 정리합니다. PR diff에는 실제로 바뀐 줄만 보이고, 파일 전체가 다시 정렬되어 묻히는 일이 없습니다.
job id와 step id는 필요한 명명 패턴에 맞는지 검사되고, 모든 job이 runs-on 또는 uses 중 하나를 갖는지 확인되며, permissions 값은 실제 열거형과 대조됩니다. 같은 트리거 안에 branches와 branches-ignore처럼 상호 배타적인 필터가 동시에 있으면 표시됩니다.
트리는 workflow의 실제 job/step 구조를 그대로 반영하며, 항목을 선택하면 에디터가 해당 줄까지 스크롤됩니다. 들여쓰기 단계를 눈으로 세어 찾을 필요가 없습니다.
os·버전 같은 변수 표를 만들고, include나 exclude 조합을 추가하고, fail-fast와 max-parallel을 설정한 뒤 생성될 실행 전략(strategy.matrix)을 미리 보고 선택한 job에 삽입합니다.
env, secrets, vars, github를 참조하는 모든 ${{ }} 표현식을 추출해 job과 step별로 나열합니다. 범위 필터로 한 종류의 참조만 골라 볼 수도 있습니다.
자주 쓰는 프리셋이나 사용자 지정 표현식으로 5필드 schedule을 만들고, on.schedule에 들어갈 내용을 미리 본 뒤 삽입합니다. GitHub 자체 예약 실행 제한이 자동으로 적용되므로 따로 외울 필요가 없습니다.
기능이 얼마나 많은지보다 경계를 아는 게 더 중요합니다.
답변은 모두 GitHub 공식 문서를 근거로 하며, 추측으로 쓰지 않았습니다.
생성된 내용 자체는 공개된 문법에 맞는 유효한 값입니다 — GitHub Actions는 2024년부터 schedule에 선택적인 IANA 타임존을 지정할 수 있게 했습니다. 다만 GitHub 공식 커뮤니티 토론에는 실제로 적용되지 않았다는 실제 사례가 여러 건 보고되어 있습니다. 이 도구가 보장하는 것은 생성된 조각이 공개된 문법과 맞는다는 점뿐이며, GitHub 스케줄러가 그것을 실제로 적용하는지까지는 보장할 수 없습니다.
몇 가지 실제 원인이 있습니다: workflow 파일이 기본 브랜치에 없거나, 저장소가 오래 활동이 없어 GitHub가 60일 뒤 schedule을 자동으로 비활성화했거나, 표현식의 간격이 문서화된 최소 5분보다 짧은 경우입니다. GitHub 문서는 부하가 높은 시간대, 특히 정시 전후로 지연이 생길 수 있다고도 밝히고 있습니다. 이 도구는 cron 문법만 검사할 뿐, 정확한 실행 시각까지는 보장하지 않습니다.
workflow를 이 GitHub Actions 워크플로우 검증 도구에 붙여넣으면 GitHub의 일반적인 메시지 대신 구체적인 job 또는 step 이름과 줄·열 위치까지 보여줍니다. 입력을 멈춘 뒤 350ms 후 자동으로 다시 검증되므로, 수정하는 동안 표시 위치도 함께 갱신됩니다.
with 블록 안에서는 env 컨텍스트 자체를 쓸 수 없기 때문입니다. 이는 공식 문서에 명시된 세 가지 제한 중 하나로(env는 step의 id나 uses에도 쓸 수 없습니다), 참조 목록이 이런 참조를 직접 표시해 줍니다. 값은 job 또는 workflow 수준의 env에 두거나, reusable workflow에 input으로 명시적으로 전달하세요.
secrets는 if: 조건 안에서 직접 읽을 수 없다는 것이 공식 문서의 제한이기 때문입니다. 먼저 secrets를 job 또는 step 수준의 env 변수에 대입한 뒤, if: 조건에서는 그 env 값을 확인하세요. 이는 참조 목록이 모든 secrets.* 참조에 대해 표시하는 세 가지 위험 위치 중 하나입니다.
따옴표 없이 쓴 3.10은 YAML에 의해 숫자 3.1로 해석되어 끝의 0이 조용히 사라집니다. 이는 YAML 파싱 방식 때문이지 GitHub Actions의 버그가 아닙니다. matrix 생성기는 버전처럼 보이는 값을 감지해서 생성된 strategy.matrix를 삽입할 때 자동으로 따옴표를 붙입니다.
이 도구가 잘못 판단하는 workflow를 발견했나요?
이 GitHub Actions 워크플로우 검증 도구에 workflow를 붙여넣고 job/step 트리와 참조 목록이 실시간으로 갱신되는 것을 확인한 뒤, 필요할 때 matrix나 cron 초안을 만들어 보세요.
모든 처리는 브라우저 안에서만 이루어집니다 — 아무것도 업로드되지 않고, workflow가 실행되는 일도 없습니다.
모든 파싱은 브라우저에서 로컬로 처리됩니다.