Websites/Plugincheck: Difference between revisions

m
Line 79: Line 79:
Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:
Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows:


1) JSON files for each plugin are stored at:
# JSON files for each plugin are stored at: https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
# From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
2) From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
# Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
3) Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
# Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
4) Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
# Trusted users who have been given merge access to the main project repo can then review the PR and merge
5) Trusted users who have been given merge access to the main project repo can then review the PR and merge
# Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
6) Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node:
# Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.
https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
7) Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.


This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.  
This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.  


However there is much more needed in terms of data translation to a DB format at caniuse, plugincheck would actually need very little, if any.
However there is much more needed in terms of data translation to a DB format at caniuse, plugincheck would actually need very little, if any.
Confirmed users
210

edits