Port health is not tied to port version/revision

[ryandesign]

The port health indicators are misleading because they are not tied to the port version/revision.

For example, mkvtoolnix was recently updated to 39.0.0. At the time of filing this ticket, the port health indicators show green for 10.14, 10.13, 10.12, red for 10.11, 10.10, 10.9, green for 10.8 & 10.7, and red for 10.6 and 10.6 i386.

But if you drill down, you discover that the statuses for 10.9 and up are for the 39.0.0_0 build while the 10.8 and earlier statuses are for the previous 30.1.0_1 build. The 10.8 and earlier builders are very busy right now rebuilding hundreds of ports for the libc++ transition and have not yet gotten around to building mkvtoolnix 39.0.0.

It seems like the status indicators for each builder need to be cleared when the port version or revision is updated. And when you get status information from the buildbot, you need to ensure that it is for the current version/revision of the port.

[mojca]

Yes, I'm painfully aware of this and I have put this on the task list (not entered in the tracker though).

The prerequisite to get this working is to make the version information easily accessible from the buildbot history, and something that you would need to deploy on our buildbot master. The only other alternative is to parse full build logs from all builds, but that will likely download plenty gigabytes from your server.

Options would be:

• quick hack to mpbb to print the version information to the "statistics" file (next to file size / build dir size / time to build)
• same or similar step as the one which prints port name that would also print port version (ideal)
• for older builds the only available option would be to parse full logs, but that would ideally need to be done from your local network, else we'll clog the server

[mojca]

Also, once we do this, we might need to somewhat extend the port health, so that it will show the health of the last build even when the newest build isn't yet ready (but make it clear that it's an older status).

[ryandesign]

• same or similar step as the one which prints port name that would also print port version (ideal)

Printing the full name @version_revision+variants spec in the builder step instead of just the name seems like a reasonable thing to do. Would that be ok?

[ryandesign]

• for older builds the only available option would be to parse full logs, but that would ideally need to be done from your local network, else we'll clog the server

What format would be best? Just a csv file for each builder with build number, port name, version, revision, variants?

I should be able to produce this data for successful builds by parsing the portbuilder logs, since the version, revision, and variants are printed as part of the archive name in the install and activate phases. If just this partial data can be imported, I'll start with this and work on the rest later.

For unsuccessful builds, variant selections can be reconstructed from the DEBUG: Executing variant foo provides foo lines in the log, but version/revision information is not available in the log. We could look at the portwatcher that scheduled it, find out from that what commit of macports-ports we were using, check out a clone at that commit, and use port info to find the version/revision.