rss-actions

Crates.iorss-actions
lib.rsrss-actions
version0.3.0
sourcesrc
created_at2022-10-13 01:26:40.632137
updated_at2024-07-10 04:26:18.087892
descriptionRun scripts automatically on rss feed updates.
homepage
repositoryhttps://github.com/boustrophedon/rss-actions
max_upload_size
id686806
size246,561
Harry Stern (boustrophedon)

documentation

README

build-test Coverage Status

About rss-actions

This is a Rust library and command-line program for tracking RSS feeds and automatically running scripts when they update.

Feeds are added with a url and alias used to refer to that feed. You can then associate multiple filters with a feed, which can be used to match certain entries in the feed based on keywords in the title of the entry. A filter also has a script associated with it which is run on each entry that's matched by the filter's keywords.

To recap, a feed has:

  • A name, called an alias
  • A url

and a filter has:

  • The feed it's associated with, referenced by alias
  • A list of keywords used to match against every entry in the associated feed.
  • A script to run on matching entries
  • A timestamp marking the last time the filter was matched (not the newest-seen entry of the feed!)

Each feed is only downloaded once, to prevent accidentally hitting rate limits when you have many filters on a single feed.

Data is stored in a local sqlite database.

Usage

Add feeds with

rss-actions add feed <alias> <url>

Add filters with

rss-actions add filter <alias> <path-to-script> [keywords...]

and then add a crontab entry or systemd timer file that calls

rss-actions update

To list feeds and filters you can use rss-actions list feeds and rss-actions list filters respectively.

Usage and deployment notes

Note that if you want the update to run as a different user than the one you ran the commands with, you'll have to copy the config file from $XDG_CONFIG_DIR/rss-actions/ and sqlite db from $XDG_DATA_DIR/rss-actions/ to the corresponding directories in the other user's home directory, or change the configuration file to point to the correct location for the database. Also make sure your scripts have the correct locations and are accessible.

Other stuff

While writing this program, I experimented with only writing "integration" tests, i.e. only in the top-level tests/ directory.

So far the only bugs that weren't caught were:

  • In my tests I was making a custom Config with a temporary database directory, and so I missed the case where the default directory (~/.local/share/rss-actions/) did not exist. This might have been caught by inspecting code coverage. In a previous project I had explicit tests for this that actually manipulated the $HOME environment variable and used a global lock so that the tests for it couldn't run in parallel (but the rest of the test suite could).

  • keyword matching was supposed to be case-insensitive but none of my tests tested that

Commit count: 36

cargo fmt