MNT: Adding more dev dependency testing

[bsipocz]

The main motivation here is to provide downstream testing for pyvo during their dev cycle

[bsipocz]

I think it would be sufficient though to run the pre-release tests from cron only? The chances are that we may not notice its failure given the constantly failing remote tests job in cron.
Is it maybe possible to have a GHA badge for the status of one job, or one workflow only, rather than one for the status of the branch? maybe @pllim knows it.

[codecov]

Codecov Report

Merging #2378 (56d2004) into main (d53047b) will not change coverage.
The diff coverage is n/a.

❗ Current head 56d2004 differs from pull request most recent head 0b11785. Consider uploading reports for the commit 0b11785 to get more accurate results

@@           Coverage Diff           @@
##             main    #2378   +/-   ##
=======================================
  Coverage   63.29%   63.29%           
=======================================
  Files         132      132           
  Lines       17241    17241           
=======================================
  Hits        10913    10913           
  Misses       6328     6328           

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[pllim]

Re: badge -- AFAIK, you cannot just have badge status for one job of many in a workflow. But you can isolate that job in its own workflow and then generate a badge for that one workflow. 🤷 https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge

[pllim]

I also wonder if your workflows could be simplified by using https://github.com/OpenAstronomy/github-actions-workflows but that is probably out of scope here.

[bsipocz]

Thanks for the badge reference, I'll have to sleep on the question of how to cut up the workflow (right now thinking of dumping the cron jobs into a separate one, but also separating out the devtesting, so we can have the badge for that one). It's not ideal to then have 3 workflows rather than just one config file, but then it's also not a big deal.

[bsipocz]

OK, so let's go ahead with this as a prototype for what pyvo downstream could do to help the integration testing of pyvo.

[bsipocz]

Double checking it looks like that none of the deps is in a RC state, so the pre-release job has to be double checked when e.g. the astropy RC comes out to make sure it's indeed picked up.

[pllim]

Sounds like a plan. Thanks!