Visualising bad package manifests on package pages

[daveverwer]

If a package has a bad manifest it is currently excluded from search and returns a 404 when queried directly.

Issue #518 restores these packages in search and gives a reasonable display for the package page, but the issue of bad package manifests is a larger one that we want to track and visualise.

There are a couple of different parts to this:

Package Analysis

While analysing packages, if the execution of swift package dump-package fails, record this data in a new field against the package version. Maybe something like valid_package_manifest as a boolean.

We could also store the output from the failed command, but it's not usually very helpful so I think a boolean is probably enough.

Package Display

When showing the package page, if any versions that are being displayed on the package page (stable, beta, default branch) have that flag set, then at the top of the page, in between the package name section and the first bulleted list metadata section there should be a new section that shows an error message for each of those versions that have a bad manifest.

I'll knock up some designs and markup for this at the point that we start to implement it.

[daveverwer]

#499 is related to this. I think we should close that one as we will need to ensure that version records are created when dump-package fails, if this plan is to work.

Looking at the versions database table, there are no required fields in it, so I don't think this will cause any issues, but /cc @finestructure to verify this.

[finestructure]

I agree, #499 (deleting versions we can’t parse) would be detrimental to finding and fixing issues. Instead we should record failures on the records in order to be able to revisit them more easily.

[finestructure]

Not entirely sure what you mean by required fields causing issues? We already keep bad version records around so just marking them as such would be purely additive.

[daveverwer]

Not entirely sure what you mean by required fields causing issues? We already keep bad version records around so just marking them as such would be purely additive.

I meant that because there are no NOT NULL fields on that table, there should be nothing that stops us from inserting even the most broken record we can think of 👍