GitHub Actions를 사용하여 지속적 통합(CI) 설정하기

문서 개발자 가이드
,
1

:mag: 개요

견고한 Discourse 확장 기능을 구축하려면 플러그인 또는 테마 컴포넌트에 지속적 통합(CI)을 포함하는 것이 현명할 수 있습니다. 이를 통해 오류를 조기에 감지하고 코드 내 버그 발생 가능성을 줄일 수 있습니다.

GitHub Actions를 사용하여 빌드와 테스트를 자동화하는 CI 워크플로를 설정하는 것은 Discourse 팀이 모든 컴포넌트에 사용하는 방법이며, 여러분도 동일한 방식을 권장합니다.

:gear: 설정 방법

GitHub Actions의 자동화 워크플로를 추가하여 오류를 감지하려면 저장소의 루트 디렉터리에 .github/workflows 폴더를 생성해야 합니다.

workflows 폴더 안에는 GitHub Actions가 실행해야 할 자동화 작업을 정의할 수 있습니다. 예를 들어, 린팅과 테스트를 위한 .yml 파일 등이 될 수 있습니다.

플러그인과 테마 컴포넌트 모두에 사용할 수 있는 템플릿 워크플로를 준비했습니다. 이 템플릿은 여기에 있는 ‘재사용 가능한 워크플로’ 정의와 연결됩니다.

템플릿 스켈레톤 저장소에서 GitHub의 이 템플릿 사용 버튼을 클릭하면 템플릿을 기반으로 한 플러그인/테마 컴포넌트 저장소를 생성할 수 있습니다.

대신, 워크플로를 추가하려는 기존 프로젝트가 있다면 관련 워크플로를 저장소의 .github/workflows/ 폴더로 복사하기만 하면 됩니다:

:electric_plug: 플러그인: discourse-plugin.yml

:jigsaw: 테마 및 테마 컴포넌트: discourse-theme.yml

:point_up: 이 템플릿은 재사용 가능한 워크플로의 특정 주요 버전으로 고정되어 있습니다. 워크플로에 적용되는 작은 개선 사항은 테마/플러그인에 자동으로 반영됩니다. 파괴적 변경 사항(예: 새로운 린터 도입)이 있을 경우 재사용 가능한 워크플로의 주요 버전을 업데이트하며, 워크플로를 새 버전으로 가리키도록 수정해야 합니다.

:tada: 자, 이제 설정이 완료되었습니다! 단순히 저장소에 커밋이나 PR을 생성하면 GitHub Actions가 워크플로를 자동으로 감지하고 작업을 시작합니다.

GitHub Actions는 각 테스트의 세부 사항을 표시하고, 실행 후 테스트가 통과했는지 실패했는지에 따라 :white_check_mark: 또는 :x: 를 표시합니다.

테스트가 실패한 경우, 세부 사항을 클릭하면 실패한 항목에 대한 정보를 확인할 수 있으며, 이는 코드에 무엇이 잘못되었고 무엇을 수정해야 하는지에 대한 단서를 제공할 수 있습니다.

예시 보기

실패 예시
실패 예시2192×1018 71.8 KB

:white_check_mark: 자체 테스트 추가

플러그인과 컴포넌트 테스트가 효과적으로 작동하려면 플러그인 또는 테마 컴포넌트에 대한 테스트를 작성하는 것이 중요합니다.

EmberJS를 사용하여 프론트엔드 테스트를 작성하는 방법에 대한 자세한 내용은 다음을 참조하세요:

Rails를 사용하여 RSpec 테스트를 작성하는 방법에 대한 자세한 내용은 다음을 참조하세요:

:bulb: 예시

여러분의 편의를 위해, 견고한 테스트가 통합된 플러그인과 테마 컴포넌트 몇 가지를 선정했습니다:

플러그인 / 컴포넌트 클라이언트 사이드 테스트 서버 사이드 테스트
Assign :link: 폴더 보기 :link: 폴더 보기
Calendar :link: 폴더 보기 :link: 폴더 보기
Reactions :link: 폴더 보기 :link: 폴더 보기
Right Sidebar Blocks :link: 폴더 보기
Tag Icons :link: 폴더 보기
Table Builder :link: 폴더 보기

이 문서는 버전 관리됩니다 - github에서 변경 사항을 제안하세요.

15개의 좋아요
How could a CI workflow for unofficial plugins be implemented?
Unexpected error in Discourse Plugin CI
6

https://github.com/discourse/discourse-theme-skeleton을 명시적으로 언급하고, 해당 파일의 변경 사항을 파악하기 위해 이를 관찰(watch)해야 한다고 언급할 수 있습니다.

4개의 좋아요
7

재사용 가능한 워크플로가 병합되기를 바랍니다. 그러면 템플릿으로 생성된 새 저장소가 템플릿 저장소의 워크플로를 직접 사용하게 되어 이 부분이 덜 중요해질 것입니다.

2개의 좋아요
8

@pfaffman님과 @Simon_Manning님, 좋은 지적 감사합니다. 이에 따라 원문을 수정했습니다.

4개의 좋아요
9

새로운 ‘재사용 워크플로’ 사용법을 포함하도록 원문(OP)을 업데이트했습니다. 워크플로 정의에 적용하는 작은 조정들은 이제 수동 작업 없이 자동으로 테마/플러그인에 반영됩니다.

3개의 좋아요
10

플러그인을 최신 tests-passed 버전과 stable 버전 모두에 대해 테스트하려면 특별히 해야 할 일이 있나요?

1개의 좋아요
11

플러그인 스켈레톤 워크플로는 다음을 사용하며, 이는 기본 브랜치인 main에 대해 테스트할 것으로 보입니다. 재사용 워크플로에는 선택 사항인 core_ref 입력이 있으며, 제가 파악한 바로는 이 값이 없으면 discourse/discourse 저장소의 기본 브랜치가 체크아웃됩니다.

jobs:
  ci:
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1

이것이 실제로 main에 대한 테스트로 제한되는지는 단정할 수 없지만, 만약 그렇다면 테스트하고 싶은 각 ref에 대해 한 번씩 실행되도록 매트릭스 전략을 추가할 수 있습니다.

jobs:
  ci:
    strategy:
      matrix:
        target: [tests-passed, stable]
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1
    with:
      core_ref: ${{ matrix.target }}
3개의 좋아요
12

네, 그렇게 하시면 됩니다. 아니면 매트릭스를 사용하지 않고 두 작업을 수동으로 작성할 수도 있습니다:

name: Discourse Plugin

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  ci:
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1

  ci-stable:
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1
    with:
      core_ref: stable

다만 참고할 점은, 이 작업들은 .discourse-compatiblity 파일을 확인하지 않는다는 것입니다. 따라서 이 방법은 해당 파일을 사용하지 않는 플러그인, 그리고 main과 stable에 동시에 호환되어야 하는 플러그인에만 적용하는 것이 좋습니다.

CDCK의 모든 공개 테마/플러그인에서는 stable 릴리스마다 discourse-compatibility에 항목을 추가하여 버전을 '동결(freeze)'합니다. 이렇게 하면 개발 중에 stable 호환성에 대해 걱정할 필요가 없습니다.

5개의 좋아요
13

두 분 모두 감사합니다.

네, 아마도 가장 직관적인 접근 방식이겠죠. 단점이라면 잠재적으로 기능(및 새로운 버그 수정)이 지연될 수 있다는 점입니다.

2개의 좋아요