GitHub Actions는 훨씬 더 좋아질 수 있음

• GitHub Actions는 생산성과 기능 면에서 유용하지만, 실제 워크플로 작성에서는 디버깅 지연, 보안 실수, 타입 부재, 공식 액션 부족이 반복적인 시간 손실로 이어짐
• 작은 수정에도 git add; git commit; git push와 브라우저 로그 확인을 반복해야 하며, 간단한 릴리스 워크플로에서도 4번의 커밋과 실패한 릴리스가 필요했던 사례가 있음
• ${{... }} 확장, pull_request_target, 넓은 GITHUB_TOKEN 기본 권한, fork의 SHA 참조는 모두 실수하기 쉬운 보안 지점이며, 특히 fork SHA는 의도한 저장소의 커밋처럼 보일 수 있음
• 액션 입력에는 type: 검증이 없고 workflow_call·workflow_dispatch와 지원 범위도 달라, 배열·객체 입력 대신 CSV식 문자열이나 평면화된 입력을 직접 처리해야 함
• push 시점 검증, 런타임 보안 체크, 개인 저장소의 기본 토큰 권한 축소, 더 엄격한 타입 체크, 더 많은 공식·준공식 액션이 워크플로 신뢰성을 높일 수 있음

---

유용하지만 반복적으로 발목 잡는 GitHub Actions

• GitHub Actions는 2019년부터 전문 프로젝트와 취미 프로젝트에서 매일 쓰일 만큼 생산성과 안정감에 큰 도움을 주는 도구임
• 기능 확장도 꾸준히 이어져 왔음
  • reusable workflows
  • OpenID connect
  • job summaries
  • GitHub Mobile 통합
• 그럼에도 실제 개발 과정에서는 큰 좌절과 시간 손실의 원인이 되기도 함

디버깅은 작은 오류에도 너무 무거움

• 릴리스 워크플로를 설정하는 과정에서 작은 오류를 잡기 위해 4개의 커밋과 4번의 실패한 릴리스가 필요했던 사례가 있음
  • 필요한 곳에 ${{ ... }}를 쓰지 않음
  • needs: 관계를 빠뜨림
• 현재 디버깅 주기는 단순한 실수 하나를 확인하는 데도 단계가 많음
  • 개발 환경에서 브라우저로 전환해야 함
  • 올바른 탭을 찾아야 함
  • Actions 요약과 상태 화면을 클릭해 들어가야 함
  • 버퍼링된 콘솔 로그를 새로고침하며 다음 오류를 찾아야 함
• 작은 변경에도 전체 과정이 30초 이상 걸릴 수 있음

• 개선 방향

  • 대화형 디버깅 셸을 제공하거나, 최소한 git add; git commit; git push 없이 작은 변경으로 워크플로를 다시 실행할 수 있어야 함
  • 저장소 설정으로 명백히 잘못된 워크플로를 push 시점에 거부할 수 있어야 함
    • 동작할 수 없는 문법
    • 존재하지 않는 job이나 step 참조
    • 잘못된 YAML 때문에 워크플로가 조용히 실행되지 않는 상황

보안 실수는 너무 쉽게 발생함

• GitHub Actions에서는 사용자가 작성한 워크플로가 의도치 않게 취약해지기 쉬움
• ${{ ... }} 확장을 셸이나 다른 실행 맥락에서 사용할 때, 확장 값이 사용자가 제어하는 입력이면 악성 코드 주입으로 이어질 수 있음
  • 예시에서는 inputs.frob를 통해 코드가 주입되고 $MY_IMPORTANT_SECRET가 유출될 수 있음
• pull_request_target은 사소하지 않은 워크플로에서 안전하게 쓰기 매우 어려움
  • 의도된 사용 사례는 fork에서 온 PR에 라벨을 붙이거나 댓글을 다는 좁은 범위로 보임
  • 하지만 실제로는 큰 foot-gun처럼 노출돼 있음
• 워크플로와 job 수준 권한도 과도하게 설정되기 쉬움
  • 일반 GITHUB_TOKEN의 기본 접근 권한은 매우 넓음
  • 개인 계정 저장소에서는 기본 토큰 권한 축소를 자주 잊게 됨
  • 필요한 권한 범위를 정확히 몰라 토큰 권한을 과도하게 부여하게 됨
• GitHub 권한 모델이 read/write/none 단일 축에 끼워 맞춰져 혼란을 더함
  • id-token: write가 워크플로의 OpenID Connect 토큰을 읽을 수 있게 함
  • 일부 security advisory GET 작업은 write 권한을 요구하고, 다른 작업은 read만 요구함

SHA 고정 액션은 fork 커밋과 헷갈릴 수 있음

• actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e처럼 보이는 참조가 실제로는 actions/checkout 저장소의 커밋이 아닐 수 있음
• 해당 SHA는 actions/checkout 네트워크 안의 fork에 있는 커밋이며, GitHub의 alternates 사용 때문에 부모 저장소에 속한 것처럼 보일 수 있음
• Chainguard의 관련 글은 문제를 세 가지로 나눔
  • fork의 SHA 참조와 대상 저장소의 SHA 참조가 시각적으로 구분되지 않음
  • GitHub REST API의 /repos/{user}/{repo}/commits/{ref}는 {ref}가 fork에만 있어도 {user}/{repo}만 참조하는 JSON 응답을 반환함
  • fork와 비-fork SHA를 구분하지 못하면 GitHub Actions의 신뢰 소스 제한을 우회할 수 있음
• GitHub의 대응은 지금까지 문서에 추가 문구를 넣는 수준이었음

• 개선 방향

  • 명백히 안전하지 않은 워크플로를 push 시점에 거부하는 paranoid workflow security 모드가 필요함
  • AddressSanitizer 같은 런타임 계측처럼, 워크플로 실행 중 보안상 위험한 패턴을 실패 처리할 수 있어야 함
    • 예: pull_request_target에서 대상 저장소가 아닌 ref로 actions/checkout을 사용하는 경우 실패
  • pull_request_target은 폐기하거나 제거하는 방안도 검토할 수 있음
  • 개인 저장소에서도 조직·엔터프라이즈처럼 기본 GITHUB_TOKEN 범위를 더 제한적으로 설정할 수 있어야 함
  • SHA가 참조된 저장소에는 없고 fork에만 있는 SHA-pinned action은 기본적으로 거부해야 함

타입 시스템은 일관성과 표현력이 부족함

• 커스텀 GitHub Action은 inputs: 아래에 입력을 정의할 수 있지만, 액션 입력에는 타입 강제가 없음
• type: number 같은 선언은 액션 입력에서 동작하지 않음
• GitHub Actions 내부에서도 타입 지원 위치가 일관되지 않음
  • workflow_call: boolean, number, string 지원
  • workflow_dispatch: boolean, choice, number, string 지원
  • action inputs: 타입 지원 없음
• 타입을 지원하는 입력도 배열이나 객체 같은 복합 데이터 구조를 지원하지 않음
  • paths: [foo, bar, baz] 같은 배열 입력 불가
  • headers: 아래에 계층 구조를 두는 객체 입력 불가
• 액션 작성자는 대신 임시 형식의 입력을 요구하게 됨
  • paths: foo,bar,baz처럼 CSV식 파싱을 직접 구현
  • header-foo, header-baz처럼 자연스러운 계층 구조를 평면화
• 이런 방식은 유지보수성과 보안에 모두 좋지 않음
  • 단일 평면 입력 네임스페이스를 직접 관리해야 함
  • 복잡한 입력을 위해 임의의 미명세 언어를 만들게 됨

• 개선 방향

  • action과 workflow 작성자가 type:을 모든 곳에서 사용할 수 있어야 함
  • choice도 workflow_dispatch에만 제한하지 않고 모든 곳에서 사용할 수 있어야 함
  • 정적으로 타입을 추론할 수 있는 경우, 잘못된 타입의 워크플로 변경을 push 시점에 거부해야 함
  • type: object와 type: array가 필요함
  • 내부 타입이 이질적일 수 있어 완벽하지는 않더라도 현재보다 나아질 수 있음
  • 필요하면 JSON 직렬화 문자열로 전달할 수 있음
  • GitHub Actions에는 이미 fromJSON(...) 함수가 있음

공식 액션은 플랫폼 신뢰와 직접 연결됨

• GitHub Actions의 서드파티 생태계에는 고품질 액션이 많음
• 그 아래에는 GitHub가 유지보수하는 공식 액션들이 있음
  • 핵심 git 작업: actions/checkout
  • GitHub 작업과 저장소 관리: actions/{upload,download}-artifact, actions/cache, actions/stale
  • 필수 설정: actions/setup-python, actions/setup-node
• 이런 액션은 범용성과 중요성이 높아 공식 유지보수 구현의 가치가 큼
• 하지만 공식 액션 수는 적고, GitHub 기능을 직접 연결하는 작업도 공식 액션으로 제공되지 않는 경우가 있음
  • 예: pull request를 merge queue에 프로그래밍 방식으로 추가하는 액션
  • GitHub CLI에는 gh pr merge가 있지만 액션으로 노출되지는 않음

• 중단된 공식 액션 사례

  • actions/create-release: 2021년 3월부터 유지보수 중단
  • 사용자는 커뮤니티 유지보수 워크플로로 이동하도록 권장됨
  • 대표적으로 softprops/action-gh-release가 언급됨
  • actions/upload-release-asset: actions/create-release와 같은 시기에 유지보수 중단 표시
  • actions/setup-ruby: 2021년 2월부터 유지보수 중단
  • 사용자는 ruby/setup-ruby로 이동하도록 권장됨
  • 전환 자체는 비교적 고통이 적었지만, 핵심 구성 요소가 버려질 수 있다는 인상은 플랫폼 신뢰에 악영향을 줌
  • 공식 고품질 액션이 부족하면 사용자는 GitHub API 표면을 직접 다루며 보안 실수를 계속 만들 수 있음

• 생태계 개선 방향

  • GitHub 인프라의 서로 다른 부분을 직접 연결하고, 현재 REST API 호출이나 gh 실행으로 수동 처리해야 하는 작업은 공식 액션으로 제공될 가치가 있음
  • 대형 서드파티 액션과 협력해 community-actions 같은 준공식 조직을 만들 수 있음
    • GitHub의 검토를 받은 액션
    • 저장소 보안 모범 사례 준수
    • 시맨틱 버전 업데이트
    • 주요 생태계 액션에 대한 명확한 신뢰 경로

기존 도구와 GitHub 로드맵

• 여러 사람이 로컬 GitHub Actions 에뮬레이션 도구인 nektos/act를 추천함
  • 단순 워크플로를 빠르게 반복하고 디버깅하는 데 유용함
  • 하지만 이미지와 이벤트가 GitHub의 실제 환경과 완전히 같지 않은 경우가 있어 손실 있는 도구로 평가됨
• rhysd/actionlint는 로컬 린팅과 보안 린팅에 사용됨
  • workflows만 lint할 수 있고 actions는 lint하지 못하는 점이 한계임
• GitHub Actions extension for VS Code는 편집기 내 lint와 저장소 워크플로 통합을 제공함
  • 공개 JSON schema를 기반으로 함
  • 실행 중인 workflow 표시, 변수 완성 등을 제공함
  • 하지만 secrets 오타나 동적으로 생성된 output 이름 오타처럼 감지하지 못하는 문제가 있어 add-commit-push 디버깅은 여전히 필요함
• GitHub Actions 프로젝트 관리 책임자 Julian Dunn은 몇 가지 진행 중인 기능과 우선순위를 공유함
  • 대화형 디버깅은 GitHub Actions의 공개 로드맵에 있음
  • 태그·SHA 기반 workflow pinning에서 더 불변적인 방식으로 이동하는 작업도 공개 로드맵에 있음
  • GitHub는 공식 액션 생태계의 건강과 품질을 우선순위로 보고 있으며, 각 액션에 충분한 유지보수와 관심을 주기 위해 공식 액션 수를 작게 유지하는 전략을 취하고 있음

[GN⁺]

Hacker News 의견들

• GitHub Actions 워크플로에는 두 가지 방식이 있음. 1) GitHub Actions로 “프로그래밍”하면서 이메일 발송 같은 것도 마켓플레이스 도구를 붙이고, YAML이 500~1000줄로 커지며 조건문이 난무해 이해하기 어려워지는 방식임
  2) GitHub Actions는 “설정”만 하고, “이 YAML 복잡도를 스크립트로 밀어낼 수 있나?”를 계속 묻는 방식임. 이메일 발송도 스크립트로 넣으면 워크플로는 50~60줄 정도로 끝나고, 로컬에서 스크립트를 디버깅할 수 있어 멍청한 push-debug-commit 반복도 거의 사라짐. 새 팀에 갈 때마다 1은 광기의 길이고 2가 합리적이라고 말하지만, 절반쯤은 여전히 1을 택함. 디버깅 도구 부족, 벤더 종속도 2를 택하면 훨씬 덜 문제가 됨

  • 이 관점에 크게 동의함. GitHub Actions를 YAML로 프로그래밍하려 하지 않고 작업 실행 기반으로만 다루면 많은 고통이 사라짐
    다만 모든 것을 제대로 된 프로그래밍 언어로 밀어 넣는 것만으로 충분하지 않을 때도 많음. GHA의 벤더별 기능을 써야 하거나, 작업 간 의존성을 표시하거나, 이미 액션으로 잘 추상화된 REST API를 호출해야 하는 경우가 있음. 원하는 언어로 다시 구현할 수는 있지만 벤더 의존이 사라지는 것도 아니고 여전히 취약함. 결국 GHA의 벤더 종속 가치 제안은 매우 강해서, 사람들을 2번으로 설득하려면 더 강한 장점이 필요함
  • 2번 방식은 개발자가 빌드를 로컬에서 실행하기도 쉬워짐. 로컬 디버깅과 테스트/스테이징/프로덕션 환경에서 같은 빌드 체인을 쓰게 되고, 서로 다른 빌드 절차를 유지하지 않아도 됨
    이는 GHA뿐 아니라 모든 빌드 서버에 해당함. 빌드 서버는 이력, 산출물 관리, 권한/감사를 더하는 스크립트 실행기여야 하고, 실제 빌드 과정은 빌드 대상 저장소에 위임해야 함
  • 좋은 관점임. 다만 GitHub 자체를 자동화하려면, 예를 들어 역할 할당이나 태그 지정 같은 작업에서는 1번이 피하기 어려움. 그래도 지금은 GHA의 끔찍한 디버그 루프를 겪느니 상당 부분을 수동으로 처리하고 싶음
    참고로 GHA 동작을 로컬에서 재현하려는 nektos/act가 있음: https://github.com/nektos/act
  • 액션은 어떻게 디버깅하는지 궁금함. commit-action-debug-change 루프에 너무 오래 시간을 쓰는 게 말이 안 될 정도임. 2번 방식이 스크립트 디버깅을 훨씬 쉽게 만든다는 데는 전적으로 동의함. CI는 로컬 실행 가능해야 하는데, GitHub Actions는 도구가 일부 있어도 그렇게 쓰기 쉽지 않음
  • 2번을 지향하는 주된 이유는 GitHub가 내려가도 로컬에서 빌드를 돌릴 수 있고, 필요하면 쉽게 다른 곳으로 옮기고 싶기 때문임
    빌드/테스트/서명/배포 등을 가능한 이식성 있게 스크립트로 작성하고, 이 스크립트는 항상 로컬에서 동작해야 함. GitHub는 그 스크립트를 실행할 환경을 자동으로 준비하고 실제로 실행하는 역할로만 봄

• git commit, push, wait 루프는 끔찍한 사용자 경험임. 사용자는 로컬 머신을 포함해 어디서나 실행되는 이식 가능한 파이프라인을 누릴 자격이 있음. Act가 이 문제를 어느 정도 해결하지만, 대체로 진짜 환경을 그대로 대표하지는 못함
  프로덕션처럼 로컬에서 실행할 수 없는 파이프라인도 많지만, 덜 중요한 개발 단계에서는 이런 워크플로를 캡처해 로컬에서 실행하지 못할 이유가 없음. Garden은 이식 가능한 파이프라인을 제공하고 전체 의존성 그래프에 걸친 캐싱을 더함. 일부 고객은 실행 시간이 80% 이상 줄었고, 개발자는 git에 먼저 push하지 않고도 테스트 통과/실패를 즉시 확인함. 오픈소스임: https://github.com/nektos/act, https://docs.garden.io

  • 사람들이 액션 안에 bash 스크립트를 욱여넣는 대신, 액션이 make나 bash 스크립트를 호출하게만 했다면 이런 문제는 없었을 것임. CI/CD와 개발자는 모두 make release 같은 동일한 대상/명령을 써야 함
  • “CI는 눈송이처럼 특별하면 안 된다”는 원칙을 DevOps와 DevOps 도구 전문 팀을 만들기 시작하면서 많이 잃어버린 듯함. 무언가가 직업이 되는 순간, 그게 지나치게 복잡해지는 전환점에 도달한 느낌임. 대문자 Agile과 시간을 채워야 하는 스크럼 마스터들에게서도 같은 현상을 봄
  • Act의 불완전함 때문에 엉뚱한 곳을 파고든 적이 여러 번 있음. 지금은 일단 예전 루프로 돌아갔고, 시간이 지나며 나아지길 바람
  • 빌드 파이프라인에도 Terraform 같은 것이 필요함. Bitbucket을 쓰고 있다면 신이 도와야 함
  • garden.io 랜딩 페이지가 iOS에서 깨져 보임. 화면 오른쪽으로 넘쳐 나감

• GH Actions 실행을 디버깅하는 고통에 전적으로 공감함. 가진 도구라고는 디버그 켜고 다시 실행하는 기능뿐임. 파이프라인을 고치거나 디버깅하려고 만든 쓰레기 커밋이 너무 많고, 대부분은 되는지 보려고 마구 던져보는 수준임
  재사용 가능한 로직 같은 아주 기본적인 일도 불필요하게 복잡하거나 문서화가 나쁨. 알고 나면 꽤 쉬웠지만 GitHub 문서는 형편없었음. 재사용성을 얻으려면 액션을 공개하거나 다른 저장소에 둬야 하는 것처럼 보였지만, 실제로는 재사용 로직을 담은 새 YAML 파일을 만들 수 있음. 다만 workflows 폴더 루트에 둬야 동작함. GH Actions는 작업하기 정말 고통스럽지만, 한번 동작하면 매우 편함. 커밋하고 push하기 전에 액션을 테스트할 로컬 러너 같은 게 있으면 좋겠음

  • 이럴 때 draft PR을 쓰는 방법이 있음. draft PR에서 액션 YAML 변경을 실행해볼 수 있고, 만족하면 실제 병합용 PR에서 적당히 커밋을 squash하면 지저분함 없이 반영할 수 있음. GH Action 로직을 디버깅하거나 개발할 때 draft PR은 꽤 괜찮았음
  • 모든 걸 하지는 못하지만 꽤 쓸 만한 도구가 있음: https://github.com/nektos/act
  • CI를 고칠 때는 항상 feature branch에 올리고 끝나면 squash merge함. 한 번에 끝나는 빠른 수정은 거의 없고 항상 3~10커밋이 됨
  • GitHub runner 이미지, 또는 그 모방 이미지를 실행해본 적이 있는데 설정과 일부 기능 동작이 너무 고통스러웠음. 이틀 뒤 포기함
    GitHub만의 문제도 아님. 다른 큰 CI 플랫폼들도 워크플로와 통합 면에서 딱히 낫지 않음. 지금은 최대한 모든 것을 스크립트화함
  • 우리가 Earthly를 만든 주된 이유가 이것임. 빌드를 로컬에서 실행하고, CI와 일관성을 얻기 위함임

• GitHub Actions는 형편없는 CI/CD 시스템임. 같은 VM에서 단계를 병렬 실행할 수 없고, 컨테이너 기반 작업은 2급 시민 취급임
  첫 번째 문제 때문에 로컬 자격 증명이나 환경 의존성 설정을 병렬화할 수 없음. google-github-actions/setup-gcloud가 1분 넘게 걸리는 걸 보면 화남. 두 번째 문제 때문에 저장소 안 Dockerfile로 CI 환경 설정을 표현하고, 이미지 내용이 바뀌면 CI가 이미지를 다시 빌드해 해당 이미지에 의존하는 워크플로를 대기시키며, 내용이 바뀌지 않았으면 다시 빌드하지 않고 이미 설치된 의존성과 함께 즉시 실행하는 구성이 매우 어려움. GitHub Actions에서는 매번 캐시를 다시 채우려 하게 됨. 캐시는 5GB 제한이 있고, 돈을 내도 늘릴 수 없으며 FIFO로 밀려나서 5GB를 넘기면 사실상 없는 거나 마찬가지임. Concourse가 정말 그리움. 병렬 작업, 사용자 정의 파이프라인 트리거, CI 환경에 SSH로 들어가 디버깅, 파이프라인 없이 일회성 작업 실행, 산출물을 만들지 않고 작업 간 디렉터리 내용 전달 같은 것들이 가능했음. GitHub Actions는 .github/workflows에 파일 하나 올리면 바로 쓸 수 있다는 쉬운 진입성 덕분에 인기 얻은 장난감 CI/CD에 가까움. 가입시키는 데는 좋지만, 초기 기능을 넘어서면 “최고”라 부르기엔 충분히 강력하지 않음

  • 5GB 캐시 제한 때문에 “빌드 캐싱이 이상하게 깨지는” 문제를 이제 조사해볼 수 있겠음. 알려줘서 고마움
  • Concourse는 훌륭함. 팀이 해체됐다는 건 몰랐는데 정말 아쉬움. Zito의 커뮤니케이션 방식도 최고였음
  • Pivotal보다는 인수 후 VMWare가 해체한 쪽에 가깝다고 봄. 내부에는 Concourse를 좋아하는 사람이 많았음. 다만 인수 전에는 떠났음
    SSH 디버깅과 일회성 작업은 정말 꿈같았음
  • Tekton은 봤는지 궁금함: https://tekton.dev/
  • 이런 문제 중 상당수를 고려한 기존 솔루션이 있음. 의견을 좀 듣고 싶음. 이메일을 공유하거나 [e-mail]으로 연락해주면 좋겠음

• GitHub가 fork와 non-fork SHA 참조를 구분하지 못해서, fork가 GitHub Actions의 보안 설정을 우회할 수 있다는 건 어떻게 아직 해결되지 않았는지 모르겠음
  보안 제어를 쉽게 우회할 수 있다면 중대한 보안 이슈임. 누군가에게 내 SHA를 쓰게 설득해야 하긴 하지만, 사회공학은 보통 쉬운 쪽임

• 솔직히 얼마나 나쁜지 부끄러울 정도임. 관계없는 빌드 실패가 우연히 마지막으로 merge한 최신 maintainer에게만 알림이 가는 것도 이상함. 새로 추가된 maintainer가 Matrix로 알려주기 전까지 내 업데이트/빌드가 일주일째 실패 중인 걸 모를 수도 있음
  cache action은 눈으로 봐도 명백하게 망가져 있는데 관리자가 없어 보임. UI가 고장 나거나 탭이 언로드되면 단계의 빌드 로그를 tail할 수도 없음. 워크플로를 작업자 노드 간에 이식 가능하게 만들 추상화도 사실상 없음. 기본 이미지는 참사에 가까움. 처음에는 그냥 너무 비대해서 짜증났는데, 파고들수록 “Linux를 모르는 Microsoft 사람이 맡았구나”라는 생각이 들었음. Nix나 Docker를 쓰는 사람을 위한 더 가벼운 이미지도 제공하려는 노력이 없음. GitHub에서 이탈 중인데, 주된 이유는 Actions가 정신이 번쩍 들게 했기 때문임. YAML로 프로그래밍하지 않는 이유는 YAML이 현대적이고 실제로 유용한 기술을 모르는 생태계 위에 VC 돈이 쏟아지며 만들어낸 불명예라고 보기 때문임

  • Microsoft가 GitHub를 인수했을 때 이런 일이 벌어질 거라는 게 뻔하지 않았나 싶음

• https://pre-commit.ci를 강하게 추천함. 관련자는 아니고 만족한 사용자일 뿐임
  아이디어는 커밋 전에 코드를 검사하고 가능하면 고치는 hook을 작성하거나 기존 hook을 쓰고, push 후 CI가 다시 검사하며 필요하면 자동으로 수정 커밋까지 하는 방식임. 자동 캐싱이 좋아서 믿기 어려울 정도로 빠르고, 로컬 개발 머신과 CI에서 같은 설정을 쓰기 때문에 디버깅 문제가 많이 줄어듦. 오픈소스에는 무료임. 자동 릴리스 같은 것은 하지 않고 검사만 하지만, 그 검사는 아주 잘함

  • Python 프로젝트에서는 여기에 tox를 함께 쓰면 특히 좋음. tox는 테스트하려는 Python 버전에 맞춰 virtualenv를 만들고 그 안에서 테스트를 실행해줌
    소스 코드 자체를 검사하려면 skip_install = True로 정적 검사도 돌릴 수 있음. 전역 도구로 tox가 설치되어 있고 필요한 Python 버전이 모두 들어 있는 컨테이너에서 실행하면 됨. 예를 들면 https://github.com/georgek/docker-python-multiversion 같은 이미지가 있음. 유지보수는 안 되지만 업데이트는 쉬움. [tox] envlist = py{310,311}, [testenv], [testenv:check]에서 pre-commit run --all-files --show-diff-on-failure를 두는 식의 보일러플레이트면 충분함

• git commit; git push; repeat 루프를 너무 많이 겪다가 https://github.com/mxschmitt/action-tmate를 발견함. 단계 사이에 셸 접속을 열어주므로 모든 문제를 해결하진 않지만, 때로는 고통을 확실히 줄여줌

• 개인적으로는 현재 actions/upload-artifact 같은 것을 쓰지 않고도 action run에 HTML 리포트를 붙일 수 있으면 좋겠음
  특히 테스트 빌드에서는 출력 HTML 리포트를 빠르게 보고 싶을 때가 많음. 지금 아는 방식은 upload-artifact나 GH Pages인데, GH Pages는 같은 저장소에 여러 리포트 출력이 있거나 최신이 아니라 과거 리포트를 빨리 보고 싶을 때 별로임. 작업 요약에 HTML 리포트 링크를 붙이고, 클릭하면 HTML을 렌더링해주는 단순한 attach-report 액션이 있으면 좋겠음. 다른 자동화 CI/CD 시스템들은 HTML 리포트 캡처와 조회를 기본으로 훨씬 풍부하게 지원함

  • HTML은 아니지만, 산출물 업로드 등을 거치지 않고 $GITHUB_STEP_SUMMARY에 Markdown 출력을 직접 추가할 수 있음

• GH Actions는 사실상 Microsoft의 “Azure Pipelines” 리브랜딩에 가깝다고 봄. TFS/VSTS/AzDO 빌드와 릴리스 파이프라인의 이전 형태들을 모두 써본 입장에서는, 이 팀은 이걸 잘하지 못함
  Azure Pipelines가 그나마 쓸 만해진 것도 그 전에 시도한 모든 접근이 말 그대로 실패했기 때문임. 커밋 없이 개인 환경에서 edit-run-debug 루프를 돌릴 수 있도록 파이프라인을 로컬에서 실행하는 프로젝트도 있었지만 당연히 취소됨: https://github.com/microsoft/azure-pipelines-agent/pull/2687/files#diff-570b52bcb927a5365c22d17a21e8e19e1ba3427c7f3ec16ea64b7b3d14e4ee20. 그래도 삶의 질을 높이는 도구는 있음. 예를 들어 문법을 인식하는 VS Code 확장: https://marketplace.visualstudio.com/items?itemName=ms-azure-devops.azure-pipelines. 조금 논쟁적으로 말하자면 YAML 대신 XML을 썼다면, 상단의 xmlns 선언만으로도 괜찮은 코드 편집기 대부분에서 별도 사용자 개입 없이 검증을 받을 수 있었을 것임. XML은 끔찍하지만, 우리가 전부 버리면서 함께 잃어버린 유용한 기능도 많음

  • GHA는 Microsoft 인수 전부터 GitHub 내부에서 독립적으로 꽤 진행 중이던 프로젝트라고 알고 있었음. GHA가 AzP 위에 다시 만들어졌다는 뜻인지, 단순히 AzP에 새 이름을 붙였다는 뜻인지, 아니면 다른 의미인지 궁금함
  • 대부분이 생각하는 것보다 더 그럴 가능성이 큼. 인수 후 AzDo 팀의 상당수가 GitHub Actions/Projects 작업으로 이동했음
  • 마지막 문단 전까지는 동의했음. XML은 눈이 아픔. 꺾쇠괄호와 camelCase의 공포보다는, 고통이 있더라도 보기 좋게 포맷된 YAML 문서를 택하겠음