Record build logs for non-default targets

[Nemo157]

Currently the build log only displays the log for the default target, e.g. https://docs.rs/crate/semver/0.10.0/builds/253654. We should record the logs for each built target, so that failures in non-default targets can be easily identified.

If some set of non-default targets do fail (especially if those targets were opted-in) we should also highlight this partial failure somehow so the crate developer may notice and fix the issue.

As part of this it would be good to migrate log storage from the database into S3, e.g. at a path like /build-logs/{build-id}/{target}.txt.

[jyn514]

We decided it would be ideal if we only showed this for targets that were opt-in. Since currently we build many targets by default, there's no way to tell that. We'll revisit this after the discussion of #532 finishes.

[jyn514]

Another point brought up by @jebrosen is that we use the same icon for builds and targets, so it's very confusing that targets has info that builds doesn't. We should probably change the icon until this is fixed.

[Nemo157]

I'm tempted to look into this soon, @jyn514 in reference to only showing these for opt-in, it seems like just showing the log on the /builds page for all builds attempted would be ok; it's just the "highlight this partial failure somehow so the crate developer may notice and fix the issue" that really needs an opt-in?

[jyn514]

@Nemo157 sure, I'm fine with displaying this on the /builds page. I'm a little concerned about bloating the size of the build logs though - maybe we could only store the log if the build failed or the build was for the default target?

[pietroalbini]

I don't think storing compressed build logs will make an impact on our storage costs, especially compared to the size of documentation.

[jyn514]

@pietroalbini remember we currently store build logs in the database, not s3. We've had storage issues on the prod server in the past, although mostly from the large docker images. I'll check how much space the build logs are taking up currently.

[pietroalbini]

@jyn514 right! we should also switch storing logs to S3.

[Nemo157]

Yes, part of this was moving build logs to S3 (@pietroalbini is it worth migrating existing logs there, or just start storing new ones there?).

[pietroalbini]

@Nemo157 I think migrating the existing logs will make the implementation simpler and it will shrink the database to a more manageable size. We don't need to do it ASAP though.