Enhancement: Test-Function to check if a bridge returns "something"
Greetings,
in regards to software quality, I wanted to suggest a new functionality that can run on a schedule on github (once a week/every two weeks or so) to check if a bridge returns content. For many bridges, this can be done without any interaction by the bridge maintainer. Every bridge that has no parameters or only checkbox/list selectors can be randomly checked. Bridges that have text fields need an additional function where the bridge maintainer should enter a value.
Every bridge that uses a text field needs to implement a function "testBridge" (using this name for the discussion, can be named something else of course) that will define a set of values that a user would chose as parameters. For text fields, at least one possible value should be entered.
Ideas:
- Implement a test that uses a bridge like a user would (calling the results of an rss feed link basically).
- For bridges that use text fields, require an implemented function "testBridge" that includes example values (at least one)
- For bridges that only use lists or checkboxes, the test should randomize the selections (maybe even run every bridge 2 or 3 times with randomized selections).
- The test output should be limited to 2-3 items since some of the bridges return hundreds of items which would not change the result of the test, only the runtime.
This is meant as a starter so please add your ideas. Sadly, my knowledge of php is probably not enough to implement the testBridge function, maybe I can help with the github actions test though.
More thoughts:
Instead of implementing a test function in php and adding a test-function that bridges need to add, we could or should make the exampleValue mandatory and use that. This way, the information is actually bound to the field in question and it actually improves useability of the bridge.
code pieces needed:
- github action that runs on schedule running a script
- said script, doing the actual checking and providing some output
- adding a warning if a text field has no exampleValue. Only for mandatory text fields!
I'm currently working on the script that does the checking. As soon as I have a first working version, I'll start a PR that other people may add stuffs to
Yeeeeahh... after a bunch of testing, I think doing it in php is probably going to be best honestly. Working with php code from either bash shell or powershell is a biiiiiiiitch. So... anyone with php knowledge open for doing this?
@joshcoales I saw that you wanted to implement this in the facebook bridge a while ago. What do you think of the general approach?
I suggest an additional php page outside of bridges that would show the results from looping through the bridges in the way I described before. Would you feel up to that?
Update: I went back to bash :)
I also have a first start. There are 4 flavors of bridge:
- Bridge with no parameters
- Bridge with parameters
- Bridge based on another bridge with no parameters
- Bridge based on another bridge with additional parameters
Examples for those
- Asrock news bridge
- Google bridge
- Mspabooru bridge
- Github pullrequest bridge
In the case of Mspabooru, it's even nested as that requires gelbooru which requires danbooru...
- is done and identifies empty returns and errors:

(output formatting and storing will be changed in the end)
Next is going to be 2, but I think that the solution will be 80% of the solution for 3 and 4.
Man, screw me sideways, I'm an idiot...
I can get the values for all 4 types by just scraping the rss-bridge main site (with all bridges whitelisted) myself.. Thats a bunch of hours wasted...
I'm doing it in a different way now. I actually build a bridge that scrapes the rss-bridge main page, gathers all bridges, retrieves the content of those bridges and then lists all bridges with issues.
I have the bridge and am listing all sites that don't need a parameter. I'm working on the others, but before they can be actually tested, there is going to be some major maintenance needed on "exampleValues" and "defaultValues"... more on that later.
Even though this has been a "talking to the wall" issue so far, I would love to get some input on some interpretation questions on bridges.
Things that are easy:
- Bridges without parameter (105 btw).
- Bridges with fields that have examplevalue/defaultvalue information and have a 1-1 relation. Example: Amazon Price Tracker
Things that are hard:
- Bridges with multiple contexts. My idea is to randomize which context to chose for each "test run", which hopefully produces a valid picture over time.
- Non-Mandatory fields with non 1-1-relations (e.g. Crewbay. "status of the boat" selection has a direct impact on selection of one of the "position wanted", but it's not deducible from the code itself.
Things that are impossible:
- Mandatory fields without examplevalue/defaultvalue (e.g Amazon, but this actually accounts for maaaaany bridges). There is no way to deduce a search value that could return an actual feed. For the initial release of the testing, I would skip the bridges and just mark them as "untestable" and adapt them one by one. Also make it mandatory for "mandatory:true" fields to have an example/defaultvalue for the future.
- Mandatory fields with non 1-1-relations (e.g Bad Dragon, even though its broken in general, good example). If 2 checkboxes are exclusive (for example a size search, one checkbox is "large", one is "small", checking both would return no feed.
I would love to get some input from you on how to handle the different bridges. I will upload my current state of bridge later.
Hi, Bocki! Automatic bridge testing feature is good idea. But you need to notice, that there are abandoned bridges. So after reporting that this bridge is not working, nothing is going to happen until this bridge will be adopted by other maintainer.
So this feature must be opted in by bridge maintainer. In this case I would suggest bridge maintainer to configure his/her own github repository to send notifications, if bridge works fine. Probably it could be done via scheduled events in github actions (https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#scheduled-events). We could make a template for that maintainer to copy-paste to his/her repository.
Hi,
I totally disagree. An abandoned and not working bridge should be flagged by rss-bridge itself, not in the repo of the "maintainer" who has abandoned it. A list of broken bridges can also be an entry point for would-be-contributors to start by fixing a bridge.
Opting in is also not an option in my opinion. From a users perspective, it's rss-bridge that is "not working". They dont neccessarily care that its a guy 3 years ago that hasn't opened github in 2 years.
this is still a good idea. i might be able to tack this better now