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

[Discourse]

개요

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

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

설정 방법

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

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

플러그인과 테마 컴포넌트 모두를 위한 템플릿 워크플로를 작성해 두었으며, 이를 활용할 수 있습니다. 이 템플릿은 여기의 ‘재사용 가능한 워크플로’ 정의와 연결됩니다.

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

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

플러그인: discourse-plugin.yml

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

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

완성! 이제 모든 준비가 끝났습니다. 저장소에 커밋이나 PR을 생성하기만 하면 GitHub Actions가 워크플로를 자동으로 감지하고 작업을 실행하기 시작합니다.

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

테스트가 실패한 경우 세부 정보를 클릭하면 실패한 항목에 대한 정보를 제공하여 코드에 문제가 무엇인지 및 무엇을 수정해야 하는지 단서를 얻을 수 있습니다.

예시 보기

자체 테스트 추가

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

EmberJS를 사용한 프론트엔드 테스트 작성 방법은 아래를 참고하세요:

• Write acceptance tests and component tests for Ember code in Discourse
• Introduction - Testing - Ember Guides

Rails를 사용한 RSpec 테스트 작성에 대한 자세한 내용은 아래를 참고하세요:

• RSpec - Behavior Driven Development for Ruby

예시

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

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

---

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

[pfaffman (Jay Pfaffman)]

You might mention GitHub - discourse/discourse-theme-skeleton: Template for Discourse themes · GitHub explicitly and note that you should watch it to take note of changes in those files.

[Simon_Manning]

@pfaffman

you should watch it to take note of changes in those files

Hopefully the reusable workflows can get merged, making this part less relevant as new repositories made from the template will use the workflows from the template repository directly.

[keegan (Keegan George)]

Thanks @pfaffman and @Simon_Manning, good points. I’ve updated the OP accordingly.

[david (David Taylor)]

I’ve updated the OP to include instructions for using our new ‘reusable workflows’. Minor tweaks we make to the workflow definitions can now be automatically applied to your themes/plugins without any manual work.

We’ve created template workflows for both plugins and theme components which you can make use of. These connect to our ‘reusable workflow’ definitions here.

…

Plugins: discourse-plugin.yml

Themes and Theme Components: discourse-theme.yml

These templates are locked to a specific major version of our reusable workflows. Small improvements we make to the workflows will automatically take effect in your theme/plugin. For breaking changes (e.g. introducing a new linter), we will bump the major version of the reusable workflows, and you will need to update your workflow to point to the new version

[merefield (Robert)]

Do I need to do anything special to have a plugin tested against latest tests-passed and stable?

[Simon_Manning]

The plugin skeleton workflow uses the following, which I think will test against the default branch, so main. The reusable workflow has an optional core_ref input and as far as I can tell, without it the discourse/discourse repository’s default branch will get checked out.

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

I can’t say whether that actually limits it to testing against main or not but if it does, you could add a matrix strategy to run once for each ref you want to test against.

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

[david (David Taylor)]

Yup that should do it. Or you can just write the two jobs out manually without using a matrix:

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

Worth noting though: these jobs won’t check .discourse-compatiblity. So this is only worth doing on plugins that don’t use that file, and need to be compatible with both main and stable simultaneously.

For all of CDCK’s public themes/plugins, we add an entry to discourse-compatibility to ‘freeze’ them at every stable release. Then we don’t need to worry about stable compatibility while developing them.

[merefield (Robert)]

Thanks to both of you.

@david

For all of CDCK’s public themes/plugins, we add an entry to discourse-compatibility to ‘freeze’ them at every stable release.

Yeah that’s probably the most straightforward approach. The only downside is it potentially holds back features (and new bug fixes)