파이프라인 DSL에 실제 로직을 포함하지 않고, 작업을 조정하는 데만 사용해야 함. 복잡한 작업은 스크립트로 만들어서 간단하게 실행할 수 있도록 해야 함. 이를 통해 GitHub Actions, Jenkins, Azure DevOps 등에서 동일한 작업을 간단하게 수행할 수 있음
GitHub Actions를 설정할 때, 사전 제작된 액션을 피하고, 단순한 셸 실행기로 사용하는 것이 좋음. Python, Ruby, Bash 등으로 스크립트를 작성하고 GitHub Action에서 이를 실행하면 로컬 테스트가 쉬워지고, 불필요한 고통을 줄일 수 있음
GitHub Actions는 특정 조건이 충족될 때만 검사를 실행할 수 있음. 하지만 이러한 규칙을 사용하면 "Pull request와 필수 검사" 문제에 직면하게 됨. 외부 서비스와 함께 사용할 때 필수 검사는 반드시 통과해야 하며, 그렇지 않으면 병합할 수 없음
'Pull request와 필수 검사' 문제를 해결하기 위한 방법으로, 각 필수 검사 워크플로우의 'no op' 버전을 생성하여 조건이 충족되지 않을 때 이를 실행하고 코드 0으로 종료하게 할 수 있음. 이 방법은 기본 기능이지만 다소 복잡한 해결책임
Travis CI는 로컬에서 CI를 테스트하기에 훌륭했음. GitHub Actions는 GitLab CI와 경쟁하기 위해 만들어졌으며, 기업 시장에서 점유율을 잃고 있었음
Buildkite를 사용해 볼 것을 추천함. GitHub Actions를 넘어서면 Buildkite가 좋은 대안이 될 수 있음. 대규모 미국 기술 회사에서 사용한 경험이 있으며, CI의 유일한 즐거운 부분이었음
GitHub Actions의 아키텍처는 보안 결정을 잘못 내리게 할 수 있음. 예를 들어, 조직 또는 저장소 비밀은 편리하지만 보안 취약점이 될 수 있음. 저장소 환경은 별도의 비밀을 가질 수 있지만, 올바른 워크플로우가 올바른 환경에만 접근할 수 있도록 해야 함
CI 시스템의 일반적인 철학은 잘못되었음. CI가 코드를 실행하는 대신, 코드가 CI를 실행해야 함. CI는 API를 제공하여 사용자가 시스템에 정보를 제공할 수 있도록 해야 함
Bazel을 사용하여 CI 도구가 Bazel 타겟을 빌드하도록 하고, 필요할 때 원격 빌드 실행을 통해 병렬성을 높일 수 있음. 이는 약 10M+ 라인 코드 또는 대규모 서비스에 적합함
GitHub에서 "필수 검사"를 지정할 수 있으며, 이는 항상 녹색이어야 함. 하지만 특정 폴더에 변경이 있을 때만 실행되므로, 다른 폴더에 변경이 있을 경우 병합할 수 없음. 모든 테스트를 실행하지 않으면 통합의 의미가 없어지므로, 테스트를 빠르게 실행할 수 있도록 해야 함
Hacker News 의견
파이프라인 DSL에 실제 로직을 포함하지 않고, 작업을 조정하는 데만 사용해야 함. 복잡한 작업은 스크립트로 만들어서 간단하게 실행할 수 있도록 해야 함. 이를 통해 GitHub Actions, Jenkins, Azure DevOps 등에서 동일한 작업을 간단하게 수행할 수 있음
GitHub Actions를 설정할 때, 사전 제작된 액션을 피하고, 단순한 셸 실행기로 사용하는 것이 좋음. Python, Ruby, Bash 등으로 스크립트를 작성하고 GitHub Action에서 이를 실행하면 로컬 테스트가 쉬워지고, 불필요한 고통을 줄일 수 있음
GitHub Actions는 특정 조건이 충족될 때만 검사를 실행할 수 있음. 하지만 이러한 규칙을 사용하면 "Pull request와 필수 검사" 문제에 직면하게 됨. 외부 서비스와 함께 사용할 때 필수 검사는 반드시 통과해야 하며, 그렇지 않으면 병합할 수 없음
'Pull request와 필수 검사' 문제를 해결하기 위한 방법으로, 각 필수 검사 워크플로우의 'no op' 버전을 생성하여 조건이 충족되지 않을 때 이를 실행하고 코드 0으로 종료하게 할 수 있음. 이 방법은 기본 기능이지만 다소 복잡한 해결책임
Travis CI는 로컬에서 CI를 테스트하기에 훌륭했음. GitHub Actions는 GitLab CI와 경쟁하기 위해 만들어졌으며, 기업 시장에서 점유율을 잃고 있었음
Buildkite를 사용해 볼 것을 추천함. GitHub Actions를 넘어서면 Buildkite가 좋은 대안이 될 수 있음. 대규모 미국 기술 회사에서 사용한 경험이 있으며, CI의 유일한 즐거운 부분이었음
GitHub Actions의 아키텍처는 보안 결정을 잘못 내리게 할 수 있음. 예를 들어, 조직 또는 저장소 비밀은 편리하지만 보안 취약점이 될 수 있음. 저장소 환경은 별도의 비밀을 가질 수 있지만, 올바른 워크플로우가 올바른 환경에만 접근할 수 있도록 해야 함
CI 시스템의 일반적인 철학은 잘못되었음. CI가 코드를 실행하는 대신, 코드가 CI를 실행해야 함. CI는 API를 제공하여 사용자가 시스템에 정보를 제공할 수 있도록 해야 함
Bazel을 사용하여 CI 도구가 Bazel 타겟을 빌드하도록 하고, 필요할 때 원격 빌드 실행을 통해 병렬성을 높일 수 있음. 이는 약 10M+ 라인 코드 또는 대규모 서비스에 적합함
GitHub에서 "필수 검사"를 지정할 수 있으며, 이는 항상 녹색이어야 함. 하지만 특정 폴더에 변경이 있을 때만 실행되므로, 다른 폴더에 변경이 있을 경우 병합할 수 없음. 모든 테스트를 실행하지 않으면 통합의 의미가 없어지므로, 테스트를 빠르게 실행할 수 있도록 해야 함