Consider less scary message for unsupported version

[0xTim]

Tangibly related to #2294 but I couldn't see any issues/discussions related to it. Have you considered a slightly different badge for Swift versions that are supported?

E.g. JWTKit no longer supports 5.8 and 5.9, which is reported as https://swiftpackageindex.com/vapor/jwt/builds

This is fine - we only support the current (and future versions of Swift at the moment). But the way the build log is reported could be confusing so some people, it's not the build failed, it's that we just don't support that version of Swift. (The VisionOS error looks valid).

Not a major issue but thought I'd raise it anyway - it was triggered by a conversation with someone who was concerned about adopting JWTKit because half the builds were 'failing' and worried about stability

[daveverwer]

That's a valid problem, especially if it's being reported to you as you describe.

There are a couple of things that spring to mind immediately that could help. One is easy and I think we should do it. One is not so easy and probably won't be implemented quickly, but is worth talking about.

First, we could add a sentence to the top of that builds page, and maybe also at the top of every individual build that says out loud that we are not (and are not trying to be) CI for Swift packages. That a failed build is not necessarily an indication of a problem with the package.

Then, skipping builds based on tools version. The interesting thing about #2294, #2125, and #727 is that we didn't consider adding a different status for those builds that we skip, and so there was no benefit other than to save us some CPU time in our build infrastructure. What might make the difference is if we consider a "tools version failure" a different kind of "failure" to a regular build error. We already extract and store tools version in our package version metadata, so it wouldn't be too hard to insert a tools version failure record before triggering a build.

We could also limit the impact of the changes by making the new "tools version failure" status as associated value enumeration inside our failure state rather than a completely new state, creating "reason for failure" metadata. We could still treat as a failure everywhere we currently do, but that could be displayed differently on the build detail page.

I'll go ahead and add both of these as open issues. I think we should do the first one fairly quickly, and I'll assign that to myself. The second one might need more discussion but we can do it on the issue.

[0xTim]

Sounds good to me! The actual package page displays a greyed out box for 5.9 which is good, don't know how simple it is to apply that to the build result pages

[daveverwer]

Yes. I don't think any changes will be necessary to the matrix view on the package page. That grey was intentionally designed to indicate "incompatible" rather than "failed".

[daveverwer]

Tracked in #3382 and #3383