Make CI and pre-commit more reproducable #33

BaumiCoder commented 2026年02月19日 16:22:16 +01:00

Task description

Some parts of the CI (and pre-commit) are currently not that stable / reproducible:

• The cargo-deny linter get new reasons to fail, without changes in the ecformat project. These came from new security issues report for some dependencies. Avoiding fails due to security issues would be an option, but how to monitor the issues to avoid that they are completely forgotten?
• The CI currenlty uses latest images (also the default of the runner is a latest image). This can lead to breaking changes, like the one fixed with 448e8b550a. Where are latest image suitable and where not? (Do actions rely on newer versions without increasing their main version?) If fixed Ubuntu versions are used for the CI this needs to be documented as maintenance need.

reason

Running the CI for older commits should be possible.

Automation (CI/CD)

The changes themselves need no automation. Only implied maintenance tasks (like updating image versions or monitoring them at least) could be automated. However, this could be also worth a follow-up issue.

Resources

• cargo-deny recommendation for handling breaking changes due to new security issues

### Task description Some parts of the CI (and pre-commit) are currently not that stable / reproducible: - The `cargo-deny` linter get new reasons to fail, without changes in the ecformat project. These came from new security issues report for some dependencies. Avoiding fails due to security issues would be an option, but how to monitor the issues to avoid that they are completely forgotten? - The CI currenlty uses `latest` images (also the default of the runner is a `latest` image). This can lead to breaking changes, like the one fixed with 448e8b550a0eb64c748215044f85a7505f9d27e1. Where are `latest` image suitable and where not? (Do actions rely on newer versions without increasing their main version?) If fixed Ubuntu versions are used for the CI this needs to be documented as maintenance need. ### reason Running the CI for older commits should be possible. ### Automation (CI/CD) The changes themselves need no automation. Only implied maintenance tasks (like updating image versions or monitoring them at least) could be automated. However, this could be also worth a follow-up issue. ### Resources - [cargo-deny recommendation](https://github.com/EmbarkStudios/cargo-deny-action?tab=readme-ov-file#recommended-pipeline-if-using-advisories-to-avoid-sudden-breakages) for handling breaking changes due to new security issues