# 비공식 플러그인을 위한 CI 워크플로우는 어떻게 구현할 수 있을까요?
**URL:** https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774
**Category:** Development
**Created:** [7월 16, 2023, 8:02오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774 "2023-07-16T08:02:44Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@thoka](https://meta.discourse.org/u/thoka)
#### Post date: [7월 16, 2023, 8:02오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/1 "2023-07-16T08:02:44Z")
커뮤니티에서 제공한 비공식 플러그인에 대해 테스트를 실행할 수 있는 CI 워크플로우에 대한 의견을 나누고자 합니다.
일부 커뮤니티는 유지보수가 확립되지 않은 플러그인에 크게 의존하고 있습니다:
> [@axierr](#):
>
> 하지만 Discourse 업그레이드 과정에서 호환성 문제로 인해 문제가 발생할까 봐 걱정됩니다. 특정 기능이 작동하지 않거나 일부 시점에서 미적인 문제가 발생하는 것보다는 서버가 다운되는 시간대에 더 우려가 큽니다.
> [@merefield](#):
>
> 이것은 무료 소프트웨어이므로 보증이 없다는 점을 인지해야 합니다.
>
> 참고로 이는 Discourse나 우리에게 대한 비하가 아닙니다. Discourse는 공식 플러그인에 대해서만 자동화된 테스트를 통해 발전해 왔기 때문에 기술적인 사실일 뿐입니다.
> [@thoka](#):
>
> 수동 테스트를 거의 하지 않고도 업데이트 중 문제를 경고하도록 플러그인에 테스트/스펙을 추가하는 견적을 요청하는 것을 제안합니다.
>
> 테스트를 모범 사례로 포함하는 다른 플러그인을 알고 계신 분이 있습니까?
플러그인 테스트는 테스트 베드로서 Discourse 설치에 의존하므로, 커뮤니티 지원 CI 워크플로우가 어떤 모습일지 궁금합니다.
일부 플러그인에는 @angus의 [activitypub](https://meta.discourse.org/t/activitypub-plugin/266794) 구현과 같은 스펙이 포함되어 있으며, 제가 이해한 바로는 이를 통해 CI 테스트가 가능해집니다.
현재, 플러그인 소스에 포함된 스펙/테스트에 따라 비공식 플러그인의 테스트를 개선할 수 있는 두 가지 가능한 방법에 대해 생각하고 있습니다:
a) 사이트 유지보수자가 스테이징 환경에서 테스트를 실행하도록 돕는 메커니즘을 구축하는 것
b) 플러그인의 마지막으로 게시된 코드를 대상으로 테스트를 실행하여 보고하는 미리 정의된 테스트 이미지를 포크하는 서비스를 제공하는 것
여러분은 어떻게 생각하시나요?
이미 확립된 워크플로우를 놓친 것이 있을까요?
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [7월 16, 2023, 8:22오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/2 "2023-07-16T08:22:47Z")
이것이 유용할 수 있습니다:
> [@GitHub Actions를 사용하여 지속적 통합 설정하기](https://meta.discourse.org/t/setup-continuous-integration-using-github-actions/240150):
>
> mag 개요 견고한 Discourse 확장을 구축하려면 플러그인 또는 테마 컴포넌트에 지속적 통합(CI)을 포함하는 것이 현명할 수 있습니다. 이를 통해 오류를 조기에 발견하고 코드에 버그가 발생할 가능성을 줄일 수 있습니다. 빌드와 테스트를 자동화하기 위해 [GitHub Actions](https://github.com/features/actions)를 사용하여 CI 워크플로를 설정하는 것은 Discourse 팀이 모든 컴포넌트에 사용하는 방법이며, 여러분도 동일한 방식을 사용하는 것을 권장합니다. gear 설정 방법 GitHub Actions를 통한 자동화된 워크플로를 추가하려면 저장소의 루트 디렉터리에 .github/workflows 폴더를 생성해야 합니다. workflows 폴더 내부에서는 GitHub Actions가 실행해야 하는 자동화 작업을 정의할 수 있습니다. 예를 들어, 린팅과 테스트를 위한 .yml 파일이 될 수 있습니다. [플러그인](https://github.com/discourse/discourse-plugin-skeleton)과 [테마 컴포넌트](https://github.com/discourse/discourse-theme-skeleton) 모두를 위한 템플릿 워크플로를 작성해 두었으며, 이를 활용할 수 있습니다…
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [7월 16, 2023, 8:36오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/3 "2023-07-16T08:36:30Z")
대부분의 Pavilion 플러그인이 현재 백엔드와 프런트엔드 테스트를 위한 CI를 갖추고 있는 것 외에도, CI의 일부인 플러그인 매니저 시스템이 있습니다. 이 시스템은 다음과 같이 작동합니다.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [7월 16, 2023, 8:39오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/4 "2023-07-16T08:39:46Z")
네, @angus 님이 공유하신 내용과 관련하여, 매일 업데이트되는 호환성 대시보드는 아래에서 확인하실 수 있습니다:
[https://coop.pavilion.tech/plugins?branch=tests-passed](https://coop.pavilion.tech/plugins?branch=tests-passed)
이 대시보드에서는 Pavilion 플러그인(그리고 때로는 다른 플러그인)이 `tests-passed` 및 `stable` 버전과 호환되는지 확인하는 검사 상태를 표시합니다. 이 대시보드는 매일 자동으로 업데이트됩니다.
물론 이는 스모크 테스트, 스펙(백엔드) 및 qunit(프론트엔드) 테스트를 포함한 다양한 테스트에 의존합니다.
예상하셨을 것처럼, 구독 플러그인(Custom Wizard)이 가장 많은 테스트 커버리지를 갖추고 있습니다. 하지만 일부 무료 플러그인도 백엔드와 프론트엔드 테스트를 모두 잘 갖추고 있습니다(예: Locations).
테스트 작성은 좋은 관행이며, 특히 비즈니스가 성장하고 성숙해지면서 Pavilion은 이 분야에서 더욱 규율 있는 자세를 취하게 되었습니다.
테스트는 의도된 기능을 문서화하는 역할도 하므로, 이는 특히 호환성 업데이트나 리팩토링 과정 중에 매우 중요합니다.
---
### Author:  [@thoka](https://meta.discourse.org/u/thoka)
#### Post date: [7월 16, 2023, 8:45오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/5 "2023-07-16T08:45:04Z")
> [@merefield](#):
>
> 이것은 매일 자동으로 업데이트됩니다.
인상적입니다. 이를 구현하는 코드를 보여줄 수 있을까요?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [7월 16, 2023, 8:49오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/6 "2023-07-16T08:49:55Z")
@angus의 다이어그램에 따른 아키텍처이며, 여러 저장소가 관여하지만 여기는 상태 서버입니다:
> **[GitHub - paviliondev/discourse-plugin-manager: Discourse plugin status server](https://github.com/paviliondev/discourse-plugin-manager)**
>
> Discourse plugin status server
또한 다음과 같은 접근 방식입니다:
- 테스트를 확인하지 않고 수정을 구현하지 않으며, 적절한 테스트가 없으면 하나를 추가합니다.
- 가능하면 먼저 테스트를 개발하고, 실패함을 보여준 후 문제를 수정하고 새 테스트가 통과하는지 확인합니다.
이렇게 하면 시간이 지남에 따라 커버리지가 쌓이게 됩니다 …
또한:
- 기존 코드에 테스트를 추가하는 것은 위험할 수 있습니다. 코드가 의도했던 동작을 잘못 해석할 수 있기 때문이죠 … 하지만 아무것도 하지 않는 것보다는 낫습니다 …
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [7월 16, 2023, 9:35오전 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/7 "2023-07-16T09:35:13Z")
모든 공식 플러그인에는 예제로 사용할 수 있는 스펙이 포함되어 있습니다. discourse-plugin-Skelton 플러그인에는 커밋할 때마다, 그리고 매일(추정) 테스트를 실행하는 GitHub Actions가 포함되어 있습니다.
---
### Author:  [@thoka](https://meta.discourse.org/u/thoka)
#### Post date: [7월 16, 2023, 1:58오후 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/8 "2023-07-16T13:58:13Z")
제 이해가 맞나요?
> [@thoka](#):
>
> 스테이징 환경에서 테스트를 실행할 수 있도록 사이트 관리자를 돕는 장치를 구축하기 위해
**a)** 이는 GitHub Actions를 통해 제공됩니다: GitHub Actions를 사용하여 적절한 스펙/테스트가 있는 플러그인은 모든 테스트가 통과하고 CI 액션의 상태가 [API](https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28)로 읽을 수 있는 경우 GitHub에 배지가 표시됩니다.
**b)** Discourse 공식 플러그인과 Pavilion 플러그인을 제외하고는, 업데이트하려는 버전에서 사용 중인 플러그인이 정상적으로 작동하는지 여부를 관리자가 자동으로 확인할 수 있는 개요가 존재하지 않나요?
플러그인 호환성에 대한 메타데이터를 검색하던 중 `.discourse-compatibility` 파일을 통해 [https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971를](https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971%EB%A5%BC) 발견했습니다.
제가 이해하기로는, 이는 반대되는 문제(플러그인에 비해 Discourse 버전이 너무 오래된 경우)에 대한 해결책인 것 같습니다.
반대 방향, 즉 Discourse에 비해 플러그인 버전이 너무 오래된 경우를 어떻게 처리해야 할까요?
`/admin/upgrade`에서 예정된 업그레이드에 대해 테스트가 실패하는 플러그인에 대해 경고를 표시할 수 있을까요?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [7월 16, 2023, 2:02오후 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/9 "2023-07-16T14:02:59Z")
> [@thoka](#):
>
> **b)** 디스커스 공식 플러그인과 파빌리온 플러그인을 제외하고, 업데이트 대상 버전에서 사용 중인 플러그인이 정상적으로 작동하는지에 대한 관리자를 위한 자동화된 개요는 존재하지 않는가요?
우리는 원래 제3자 개발자들이 자신의 플러그인을 등록할 수 있도록 브랜드 없는 플러그인 대시보드 버전을 제공하고 있었습니다. 그러나 제3자 플러그인 개발자 인구가 매우 적기 때문에 이 시도는 큰 반응을 얻지 못했습니다.
제3자 디스커스 플러그인 개발은 상당히 니치한 분야이며, 좋은 테스트 커버리지를 갖춘 제3자 플러그인을 제공하는 것은 _매우_ 니치한 분야입니다! 😅
이 분야의 프리랜서 중 상당수는 이미 파빌리온이나 CDCK(또는 시간이 지나면 둘 다!)에 합류했습니다.
결국 우리는 대시보드를 브랜드가 있는 커뮤니티 사이트로 통합하기로 결정했습니다.