Open mmhat opened 2 months ago
Regarding get-tested
having --oldest-only
or --newest-only
, this is very reasonable.
Regarding how the action controls it, I'll have to think about the ergonomic and how to implement. But I'll get onto the flags today.
By the way, @mmhat you named *-only
, the "only" means that passing --newest-only
and --latest-only
will result in a conflict.
Do you think there is value in allowing --newest
and --oldest
simultaneously? I feel like preventing their combination could be overly restrictive.
By the way, @mmhat you named
*-only
, the "only" means that passing--newest-only
and--latest-only
will result in a conflict. Do you think there is value in allowing--newest
and--oldest
simultaneously? I feel like preventing their combination could be overly restrictive.
Theoretically they won't conflict if the tested-with
stanza contains only version, but I think that's an edge case not worth supporting. So, yes, they should be mutually exclusive, and get-tested
should fail if both are given.
EDIT: Ah, I saw you found a different solution in #53 . I like it!
In https://github.com/Kleidukos/print-api/pull/16#discussion_r1739917913 and in https://github.com/Kleidukos/print-api/issues/24#issuecomment-2323607876 I expressed the need for more information in the build matrix generated by
get-tested
. For example, given a stanzaI think it was nice if
get-tested
indicates what the oldest and the newest GHC version in thetested-with
field is. The build matrix I envision could be something like:With those additional fields at hand it would be possible to run some jobs/steps only for the oldest or the newest version respectively.
Also, it was nice if get tested had options like
--oldest-only
(oldest-only: <true|false>
in the GH action) and--newest-only
(newest-only: <true|false>
in the GH action) to generate a matrix containing only the oldest or newest version.A potential usecase is https://github.com/Kleidukos/print-api/issues/24.