Automate README version updates via GitHub Actions

[auroranavas]

Currently, the README explicitly lists the supported versions for mal-toolbox and mal-simulator. Manually updating these versions every time these packages update risks our documentation falling out of sync with the rest of the MAL infrastructure. Especially, if the updates don't affect the tutorials.

I propose implementing a CI/CD pipeline using GitHub Actions that works as an automated integration test and auto-documentation tool. When a new version of either package is released, it should trigger a workflow in this repository. Alternatively, we could run the action weekly if we don't want to touch mal-toolbox and mal-simulator. Then, the action would:

1. Install the newly updated packages.
2. Run the tutorial scripts (e.g., python tutorial2_simulation.py) to verify compatibility.
3. If the scripts execute successfully without crashing, modify the version strings in the README.
   3.1. If it does crash, send a notification to email or Slack.
4. Commit and push the updated README directly to the main branch.

[mrkickling]

I support something like this. Having a CI job is the best approach in my opinion.

3.1. If it does crash, send a notification to email or Slack.

This will be automatically happening if it is run in the pipeline of Github (at least it will be a github notification)

But one thing is that in theory at least, if we don't update the MAJOR part of the package version number nothing in the API should break (for example 3.0.0, 3.1.0, 3.9.0 should all have the same API and not contain breaking changes while 4.0.0 would). As we know this hasn't always been a promise we keep, but it should be.

Still, having a CI job that runs the scripts is good either way since it checks the code is not broken. Updating README to contain latest tested version is also valid.

[mathiasekstedt]

I agree. Good idea. Can you implement it?

[auroranavas]

Yeah! I can implement it.

But one thing is that in theory at least, if we don't update the MAJOR part of the package version number nothing in the API should break (for example 3.0.0, 3.1.0, 3.9.0 should all have the same API and not contain breaking changes while 4.0.0 would). As we know this hasn't always been a promise we keep, but it should be.

This is totally true; however, since it is going to run once a week, it will not take much resources to compile the code, even if there has not been a breaking change.

I also think it is better to trigger the job weekly instead the job being activated by an update of toolbox and/or simulator. It would be a bother to test that, wouldn't want to mess with the releases for this.

[mathiasekstedt]

Good. Agree, lets go for the weekly run.

[mrkickling]

I was thinking of running it every time the tutorial is updated, but that would not fulfill the needs so I agree with weekly. Is it possible to run github jobs weekly?

[auroranavas]

I am pretty sure! I think this could be applied https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule