Don't try to delete rustdoc files for binary releases

[jyn514]

This avoids confusing errors like the following:

Error: failed to delete the crate

Caused by:
    <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>MalformedXML</Code><Message>The XML you provided was not well-formed or did not validate against our published schema</Message><RequestId>9F280BB6EBFEC7F3</RequestId><HostId>sgrbwS6rXn83txaNR4V3+YyVm/+VhIrD1Nhaiv9og8H5hNnGq2yntXaGt45DQ8rcmopLRGoPqkg=</HostId></Error>

Tested locally like so:

$ cargo run build crate regex 1.4.1
$ cargo run build crate bat 0.12.1
$ psql postgresql://cratesfyi:password@localhost:15432
cratesfyi=# select path from files where path like '%bat%';
             path
------------------------------
 sources/bat/0.12.1.zip
 sources/bat/0.12.1.zip.index
(2 rows)

cratesfyi=# select path from files where path like '%regex%';
             path
-------------------------------
 rustdoc/regex/1.4.1.zip
 rustdoc/regex/1.4.1.zip.index
 sources/regex/1.4.1.zip
 sources/regex/1.4.1.zip.index
(4 rows)

cratesfyi=# \q
$ cargo run database delete version regex 1.4.1
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/cratesfyi database delete version regex 1.4.1`
$ psql postgresql://cratesfyi:password@localhost:15432
cratesfyi=# select path from files where path like '%regex%';
 path
------
(0 rows)

cratesfyi=# select path from files where path like '%bat%';
             path
------------------------------
 sources/bat/0.12.1.zip
 sources/bat/0.12.1.zip.index
(2 rows)

cratesfyi=# \q
$ cargo run database delete version bat 0.12.1
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/cratesfyi database delete version bat 0.12.1`
$ psql postgresql://cratesfyi:password@localhost:15432
cratesfyi=# select path from files where path like '%bat%';
 path
------
(0 rows)

cratesfyi=# \q

Fixes #899.

r? @syphar

[syphar]

Manual test looks good.

Do you mind adding a test for deleting binary releases?

[syphar]

nit: this comment feels unnecessary here.

[jyn514]

Hmm, I'm not sure what an automatic test would look for - just make sure all the proper files are deleted? The change here is "don't try to do something that had no effect", so I'm not sure how we could test that without spinning up a full min.io instance and replaying the logs somehow.

[syphar]

I was under the impression there was an error happening before this change? ( I admit I didn't check the current state while testing)

We already install minio in GH actions, which is why I assumed that we are already running our tests against it, though looking at the config I'm not sure any more

[syphar]

Hm... I see previously it didn't fail locally / with minio, so a test for this would be hard.

Approving

[jyn514]

I was under the impression there was an error happening before this change?

The error happens when:

• You try to delete a crate version
• for a release that's a binary and not a library
• and uses the S3 backend instead of the database backend

I haven't tested to see if it reproduces with min.io or if it only happens in prod.