# How could a CI workflow for unofficial plugins be implemented?

**URL:** <https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774>\
**Category:** Development\
**Created:** [July 16, 2023, 8:02am 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:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [July 16, 2023, 8:39am UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/4 "2023-07-16T08:39:46Z")

</div>

Yes, and to add to what @angus has shared, you can find our daily compatibility dashboard here:

[https://coop.pavilion.tech/plugins?branch=tests-passed](https://coop.pavilion.tech/plugins?branch=tests-passed)

Which displays status of checks for compatibility of Pavilion Plugins (and sometimes others) against `tests-passed` and `stable`. This is updated every day, automatically.

This of course relies on tests, including smoke tests, specs (backend) and qunit (front end) tests.

Our subscription plugin (Custom Wizard) has the most test coverage, as you might imagine, but some of our free plugins include a good suite of both back-end and front-end tests (e.g. Locations).

Writing tests is good practice and certainly Pavilion has become yet more disciplined in this space as we have matured as a business.

Critically tests also document your intended functionality, which is extremely important especially during compatibility updates or refactoring.

---

_[View the full topic](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774)._