The main manual task for Solana4j is currently testing new Solana releases. Before LMAX rolls out a new Solana version internally, we ensure that upstream Solana4j is compatible with the release. It would be great if we could automate this lifecycle entirely.

The Solana version being used in tests is already defined as a property here, so why not automatically update it?

This is how I imagine this working, but I'm raising this issue so we can discuss:

On every commit, GitHub Actions will use a matrix build to run the testsuite against each the validator version being used by the public endpoint of each of the Solana networks (and any other notable Solana forks). We'd also test against the latest releases on https://github.com/anza-xyz/agave/, https://github.com/pyth-network/pythnet, and https://github.com/firedancer-io/firedancer. Although GitHub could pull this information at runtime (using a technique like https://thekevinwang.com/2021/09/19/github-actions-dynamic-matrix), I'd personally rather have it defined in a properties file for easier reproducibility.

That means we'd need a second GitHub Action running on a schedule, polling those networks and automatically updating the properties file. This could be done as a pull request, but provided it's safe we can probably just let it commit directly (the goal is to remove the need for human involvement here). It'd also be cool if we could automatically raise a GitHub issue if the test on a new release fails so a human can investigate.