badges for executable-only packages are messed up

rust-lang / docs.rs

crates.io documentation generator

https://docs.rs

MIT License

997 stars 198 forks source link

badges for executable-only packages are messed up #1860

Open Gankra opened 2 years ago

Gankra commented 2 years ago

I filed this downstream but as noted in that description, docs.rs isn't really giving shield.io much to work with to handle the issue.

Downstream issue: https://github.com/badges/shields/issues/8440

Either builds.json should set build_status: true (?) for executables, or it should include an extra flag saying "oh this was just an executable, there was nothing to build".

("Why are you even using the shield" -- because it's a common idiom and what a lot of people reflexively reach for when checking for docs, even if it will just link something containing the README again, with just a bit more metadata like flags.)

syphar commented 2 years ago

I don't see any issue exposing this in the builds.json output. I'm happy to review a PR implementing this change.

Mentoring instructions:

web::releases::build_list_handler
add releases.is_library field to the SQL statement & JSON output, the same way as we read & expose releases.rustdoc_status right now.
adapt the tests accordingly
no need to show this in the interface.

calebcartwright commented 2 years ago

~~Just want to add that we'll happily update things on the Shields.io side once this is in place :+1:~~

Actually I misunderstood, thought the response structure was going to be changed, but doesn't sound like that'll be necessary

Nemo157 commented 2 years ago

I think we probably do want to change the structure, add a has_library: bool field to it (the naming is_library in the database is subtly wrong since a package can contain both a library and some binaries). We may supporting documenting binaries in the future which would give build_status: true, has_library: false.