Closed Kleidukos closed 5 days ago
would love to see this, as well!
Duplicate #3646
(@Kleidukos you opened this one too 😉)
Wait but that’s a discussion?
It's in the "Request a feature" category
@qwerty287 haha sorry, looks like senility comes for us at all ages. :)
Clear and concise description of the problem
As a user of Woodpecker I want to be able to have one place in my repository where my list of supported compiler versions is written down, and have a woodpecker workflow to generate a matrix of jobs based on it.
I developed the get-tested tool for the Haskell ecosystem because we have a way to declare the tested versions of the compiler as metadata of the package file.
See
https://flora.pm/packages/@haskell/text ![Screenshot 2024-07-05 at 10-54-58 @haskell_text](https://github.com/woodpecker-ci/woodpecker/assets/29253044/083fb667-479c-4608-bbfc-f23d9c7529fe)This enables us to keep this list of tested compiler versions in one place, thus avoiding de-synchronisation problems between what we declare as tested and what is actually tested.
Suggested solution
Much like how GitHub does it, a well-defined JSON object format could be generated by one job on which another depends and reads from. This JSON object would mimick the YAML format:
With ideally the addition of an
exclude
property that would prevent a combination of values from being run.Main inspiration is https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs
Alternative
Maintaining multiple lists of supported compiler versions (one for package metadata, one for CI), which is prone to error and de-synchronisation.
Additional context
The link of the first checkbox (https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use) returns a 404.
Validations
next
version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]