- remove the use of environment variables to get directory paths,
- make use of arguments / argparse instead of environment variables in `update.py` and `report.py`,
- automatically guess the data directory in `latest.py` based on the script's location,
- propagate log level to auto scripts,
- move `list_configs_from_argv` from `endoflife` module to `releasedata` module,
- use `list_products` in `latest.py` to load the product's frontmatters.
Align custom scripts with generic scripts, making them configurable. This has a few advantages:
- script code is more unified,
- no more hard-coded method names in scripts, which is less error prone and make it easier to rename scripts,
- no more hard coded product names in scripts, which is less error prone and make it easier to rename products,
- less hard-coded URLs and regexes in scripts, which makes auto-configuration more expressive / updatable,
Also added method `endoflife.list_configs_from_argv()` so that it is easier to manipulate scripts arguments.
The update.py script logs loaded product data. As they are not contained
within a log group, they clutter the GitHub Actions log without really
providing any benefit. By moving them into a group, they are hidden by
default.
Replace request_html by playwright, as request_html, as it is [not maintained anymore](https://pypi.org/project/requests-html/) and scripts using it, such as artifactory.py, started to fail.
Support retrieving and updating generic release-level data, such as support and eol dates. The JSON format has been changed accordingly to add a new top-level `releases` key.
The `aws-lambda.py` script has been updated to make use of this new feature.
Until now products could declare multiple auto-update methods, but they all had to be of the same kind.
For example if you used the git auto-update method, you could not use an additional github_releases or custom auto-update method.
This is an issue as it prevents us to extend the auto-update process, for example by having a product using the 'git' auto-update method to retrieve all the versions, and a custom script to retrieve support and EOL dates.
This improve the scripts execution orchestration to be able to support auto configurations using a mix of methods, meaning:
- multiple kind of methods, such as git and github_release,
- or multiple custom methods.
A side-effect of those changes is that now a failure in a generic script does not cancel the update of subsequent products.
Another side-effect, unwanted this time, is that now custom scripts managing multiple products, such as apple.py, are now executed multiple times instead of once.
Up to now extra version fields were ignored: only name and date fields were accepted. This changes that by retaining the full JSON data when reading the file, making it possible in the future to support custom fields.
This also fixes a bug with versions having released on the same date: they was not ordered as expected (reverse order).
This makes the format open for extension, such as adding release cycle level data (such as EOL dates).
Version data is still accessible by the version's name. While this repeats the version name, it's also much more convenient for users of those data.
A few other things have also been updated in the process:
- verbosity of the diff has been increased in update.py to make workflow summaries more readable,
- dates without timezone are now set to UTC by default (this was already supposed, so no impact expected here).
Reasons were:
- one language make it easier for maintenance,
- workflow simplification,
- not stopping when a script fails anymore (it's better to have a partial update than nothing),
- use `GITHUB_OUTPUT` instead of the deprecated `set-output` command,
- display a workflow summary with statistics about scripts and information about updated products.
The commit message is not as good as it used to be, but it makes the diff process agnostic from the file format (will be needed soon when it will change), and it handles versions updates / removal, which was not supported by the previous script.
