Open daveverwer opened 1 week ago
I think adding a build with status unsupported
is a great idea. The reason I abandoned not triggering builds that have outdated tools versions was that the trigger query would get way too complicated if we did that.
However, we can just insert a build record during analysis when we first discover a new version. That way we don't need to touch the trigger query at all. It'll just not select those builds to begin with.
In terms of how to record it, I think we should aim for giving it a proper status like unsupported
. Given it's an enum we'll see where it's being used and where we might face trouble.
But by giving it a new case we'll have an easier time extending the result representation in the build details page where we can then easily show those builds as unsupported instead of failed.
This would also allow us to perhaps extend this to platforms in the future. We've had a couple of inquiries how to mark a platform as unsupported and so far the recommendation was to add an #if ... #error ...
. With this mechanism in place, we could add a new key to .spi.yml
where authors can declare a platform unsupported and we skip all its builds in exactly the same way as we would for tools-version.
In terms of how to record it, I think we should aim for giving it a proper status like
unsupported
. Given it's an enum we'll see where it's being used and where we might face trouble.
My thought was that this might make our aggregation up to the matrix more complex, but it works either way.
@daveverwer I should have some free time starting Sunday and would like to tackle this.
@daveverwer I should have some free time starting Sunday and would like to tackle this.
Thank you for the offer of help! We are always happy to accept contributions. This one might be a little tricky to do as a first issue, but let's chat about it. If you use Discord, join us on our server and we can chat about it.
First discussed in https://github.com/SwiftPackageIndex/SwiftPackageIndex-Server/discussions/3381
The more I think about this, the more I think we should do it. Scoping this to being a failure reason rather than a full new state for a build to be in should make the impact of the change much simpler and it would be a step forward for our build reporting, as well as giving us the minor speed increase we'd get from not round-tripping to the build infrastructure.