thoka
(Thomas Kalka)
1
커뮤니티에서 제공한 비공식 플러그인에 대해 테스트를 실행할 수 있는 CI 워크플로우에 대한 의견을 나누고자 합니다.
일부 커뮤니티는 유지보수가 확립되지 않은 플러그인에 크게 의존하고 있습니다:
플러그인 테스트는 테스트 베드로서 Discourse 설치에 의존하므로, 커뮤니티 지원 CI 워크플로우가 어떤 모습일지 궁금합니다.
일부 플러그인에는 @angus의 activitypub 구현과 같은 스펙이 포함되어 있으며, 제가 이해한 바로는 이를 통해 CI 테스트가 가능해집니다.
현재, 플러그인 소스에 포함된 스펙/테스트에 따라 비공식 플러그인의 테스트를 개선할 수 있는 두 가지 가능한 방법에 대해 생각하고 있습니다:
a) 사이트 유지보수자가 스테이징 환경에서 테스트를 실행하도록 돕는 메커니즘을 구축하는 것
b) 플러그인의 마지막으로 게시된 코드를 대상으로 테스트를 실행하여 보고하는 미리 정의된 테스트 이미지를 포크하는 서비스를 제공하는 것
여러분은 어떻게 생각하시나요?
이미 확립된 워크플로우를 놓친 것이 있을까요?
angus
(Angus McLeod)
3
대부분의 Pavilion 플러그인이 현재 백엔드와 프런트엔드 테스트를 위한 CI를 갖추고 있는 것 외에도, CI의 일부인 플러그인 매니저 시스템이 있습니다. 이 시스템은 다음과 같이 작동합니다.
네, @angus 님이 공유하신 내용과 관련하여, 매일 업데이트되는 호환성 대시보드는 아래에서 확인하실 수 있습니다:
https://coop.pavilion.tech/plugins?branch=tests-passed
이 대시보드에서는 Pavilion 플러그인(그리고 때로는 다른 플러그인)이 tests-passed 및 stable 버전과 호환되는지 확인하는 검사 상태를 표시합니다. 이 대시보드는 매일 자동으로 업데이트됩니다.
물론 이는 스모크 테스트, 스펙(백엔드) 및 qunit(프론트엔드) 테스트를 포함한 다양한 테스트에 의존합니다.
예상하셨을 것처럼, 구독 플러그인(Custom Wizard)이 가장 많은 테스트 커버리지를 갖추고 있습니다. 하지만 일부 무료 플러그인도 백엔드와 프론트엔드 테스트를 모두 잘 갖추고 있습니다(예: Locations).
테스트 작성은 좋은 관행이며, 특히 비즈니스가 성장하고 성숙해지면서 Pavilion은 이 분야에서 더욱 규율 있는 자세를 취하게 되었습니다.
테스트는 의도된 기능을 문서화하는 역할도 하므로, 이는 특히 호환성 업데이트나 리팩토링 과정 중에 매우 중요합니다.
thoka
(Thomas Kalka)
5
인상적입니다. 이를 구현하는 코드를 보여줄 수 있을까요?
@angus의 다이어그램에 따른 아키텍처이며, 여러 저장소가 관여하지만 여기는 상태 서버입니다:
또한 다음과 같은 접근 방식입니다:
- 테스트를 확인하지 않고 수정을 구현하지 않으며, 적절한 테스트가 없으면 하나를 추가합니다.
- 가능하면 먼저 테스트를 개발하고, 실패함을 보여준 후 문제를 수정하고 새 테스트가 통과하는지 확인합니다.
이렇게 하면 시간이 지남에 따라 커버리지가 쌓이게 됩니다 …
또한:
- 기존 코드에 테스트를 추가하는 것은 위험할 수 있습니다. 코드가 의도했던 동작을 잘못 해석할 수 있기 때문이죠 … 하지만 아무것도 하지 않는 것보다는 낫습니다 …
pfaffman
(Jay Pfaffman)
7
모든 공식 플러그인에는 예제로 사용할 수 있는 스펙이 포함되어 있습니다. discourse-plugin-Skelton 플러그인에는 커밋할 때마다, 그리고 매일(추정) 테스트를 실행하는 GitHub Actions가 포함되어 있습니다.
thoka
(Thomas Kalka)
8
제 이해가 맞나요?
a) 이는 GitHub Actions를 통해 제공됩니다: GitHub Actions를 사용하여 적절한 스펙/테스트가 있는 플러그인은 모든 테스트가 통과하고 CI 액션의 상태가 API로 읽을 수 있는 경우 GitHub에 배지가 표시됩니다.
b) Discourse 공식 플러그인과 Pavilion 플러그인을 제외하고는, 업데이트하려는 버전에서 사용 중인 플러그인이 정상적으로 작동하는지 여부를 관리자가 자동으로 확인할 수 있는 개요가 존재하지 않나요?
플러그인 호환성에 대한 메타데이터를 검색하던 중 .discourse-compatibility 파일을 통해 https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971를 발견했습니다.
제가 이해하기로는, 이는 반대되는 문제(플러그인에 비해 Discourse 버전이 너무 오래된 경우)에 대한 해결책인 것 같습니다.
반대 방향, 즉 Discourse에 비해 플러그인 버전이 너무 오래된 경우를 어떻게 처리해야 할까요?
/admin/upgrade에서 예정된 업그레이드에 대해 테스트가 실패하는 플러그인에 대해 경고를 표시할 수 있을까요?
우리는 원래 제3자 개발자들이 자신의 플러그인을 등록할 수 있도록 브랜드 없는 플러그인 대시보드 버전을 제공하고 있었습니다. 그러나 제3자 플러그인 개발자 인구가 매우 적기 때문에 이 시도는 큰 반응을 얻지 못했습니다.
제3자 디스커스 플러그인 개발은 상당히 니치한 분야이며, 좋은 테스트 커버리지를 갖춘 제3자 플러그인을 제공하는 것은 매우 니치한 분야입니다! 
이 분야의 프리랜서 중 상당수는 이미 파빌리온이나 CDCK(또는 시간이 지나면 둘 다!)에 합류했습니다.
결국 우리는 대시보드를 브랜드가 있는 커뮤니티 사이트로 통합하기로 결정했습니다.
