Dependabot 풀 요청을 Github Actions와 자동으로 병합하는 방법은 무엇입니까?

최근에 저는 이 블로그를 산업화하기 위해 많은 노력을 하고 있습니다(어쩌면 너무 과한 것일 수도 있습니다). 이 블로그는 저의 놀이터입니다. 저는 실험하고, 놀고, 테스트합니다. 나는 그것이 과도하게 설계되었다는 것을 인정하지만 나는 그것으로 많은 재미를 느끼고 있습니다. 😅

릴리스 이후 내 리포지토리의 github에서 dependabot을 사용하려고 했습니다. 큰 확신없이 처음에. 원칙적으로 대단하다고 생각한 만큼 하루에 수십 개의 공개 PR이 만들어내는 노이즈가 정말 거슬렸습니다. 다양한 오픈 소스 프로젝트의 관리자로서, 나는 dependsabot PR 홍수의 피해자가 여러 번 있었습니다. 진짜 악몽.

어리석게도 구성하려고 노력하지 않았습니다. 최근에 한번 더 기회를 줘야겠다고 생각했습니다. 그래서 워크플로에 this configuration that allowed me to update my JS dependencies and used github actions을 설정했습니다.

version: 2
updates:
  - package-ecosystem: 'npm' # See documentation for possible values
    directory: '/' # Location of package manifests
    open-pull-requests-limit: 25
    schedule:
      interval: 'daily'
  - package-ecosystem: 'github-actions' # See documentation for possible values
    directory: '/' # Location of package manifests
    open-pull-requests-limit: 25
    schedule:
      interval: 'daily'

거짓말이 아닙니다. 이 구성을 사용하면 Gatsby와 함께 개발한 이 블로그Dependabot에서 주당 최대 20개의 풀 요청을 열었습니다.

⚠️ 제한

처음에 모든 종속성 업데이트와 함께 모든 PR이 열리는 것을 보면 매우 만족합니다. 그러나 이것을 매주 관리하는 것은 정말 시간이 많이 걸립니다. 또한 이러한 PR을 체인으로 병합할 때 병합을 방지하는 package.json 파일에서 캐스케이드 충돌이 발생합니다 😒. 따라서 종종 dependsabot이 자체적으로 PR을 리베이스하여 테스트가 통과할 때까지 기다린 다음 풀 요청이 병합될 때까지 기다려야 합니다.

♻️ 자동으로 합치자!

이 블로그에서 E2E 테스트를 설정한 후 지속적 통합 워크플로에서 제공하는 확인 ✅은 매우 안심이 됩니다. You can have a look at this article which describes how I set up these tests

이 자동화를 통해 나는 dependsabot 업데이트 PR을 병합할 때 매우 조용합니다. 그래서 "E2E 테스트를 통과한 PR을 자동으로 병합하지 않는 이유는 무엇입니까?"라고 생각했습니다.

이를 위해 지속적 통합 워크플로우에서 이 방식으로 구성된 새 작업을 추가하기만 하면 되었습니다.

 dependabot:
    name: 'Dependabot'
    needs: [build, e2e] # After the E2E and build jobs, if one of them fails, it won't merge the PR.
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' && github.event_name == 'pull_request'}} # Detect that the PR author is dependabot
    steps:
      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --merge "$PR_URL" # Use Github CLI to merge automatically the PR
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

If you want to see the real example, take a look at this blog workflow.

👮‍결국 정말 안전한가요?

Sdependabot이 무엇인지 설명하지 않고 이 모든 것이 더 많은 보안을 가져올 수 있다고 생각할 수 있습니다. 실제로 보안 패치가 제공되는 즉시 수동으로 조작할 필요 없이 자동으로 적용되고 내 블로그에 배포됩니다.

Dependabot의 PR을 병합할 수 있는 가능성이 제한되어 자동화를 설정하면 상황이 개선된다고 말할 수 있습니다. 내 사이트에서 너무 중요한 것을 깨뜨리지 않도록 하는 좋은 E2E 테스트 전략은 정말 편리해 보입니다.

그러나 결국 누가 업데이트를 제어하고 업데이트에 포함된 내용은 무엇입니까? 악성 코드가 포함되어 있지 않은지 누가 확인합니까? 이 블로그는 저에게 샌드박스가 아니므로 크게 문제가 되지 않습니다. 따라서 설정하기 전에 신중하게 생각하십시오.