Incorporate the new builders

[mojca]

According to @ryandesign the old builders will stay offline for a while in order to be able to access the logs, while the new builders (dropping the _legacy suffix) will soon get online, building binaries against the libc++ library, so we will never get two builders running in parallel.

For that reason I expect the port health to show just a single entry per OS, showing the latest build on either the new "non-legacy" builder, or on the old "legacy" builder, whichever came last. Filter based on builder should probably also show just a single entry per OS/arch pair.

In a not too distant future we expect to switch to a new setup where builder names might change again (at the moment dots are forbidden in names, for example), and we would want to keep the relationship of a single OS/arch pointing to potentially multiple different builders.

It would be nice to prepare for this sooner than later, ideally before Ryan turns the builders back on.

At the moment we are using

(builder_name, build_id, port_name, status, ...)

for individual builds, where builder_name might be something like 10.6_i386_legacy.

Maybe we need an additional column pointing to "10.6_i386", so that both old builder name 10.6_i386_legacy and the new 10.6_i386 (as well as potentially future 10_6_i386) would point to the same "logical unit" of a 32-bit 10.6 worker (either as a string or an integer pointing to a different table)? Maybe we would want to add some version as well? Ideas welcome.

@umeshksingla @neverpanic

[jmroot]

It would be nice to prepare for this sooner than later, ideally before Ryan turns the builders back on.

They've been on for a few hours FYI.

[arjunsalyan]

We can add a new column os_id to the Builder table:

pk	name	os_id
1	10.6_x86_64	1
2	10.6_x86_64_legacy	1
3	10.6_i386_legacy	2
4	10.6_i386	2

And the BuildHistory table could remain same:

builder_name	build_id	status	port_name	time_start	...
1	3456	build successful	portA	2019-09-20 19:03:57	...

builder_name field is the foreign key to the Builder table.

And then we could simply use os_id instead of the currently being used name field to filter the build history related to that builder.

Are you suggesting the same?

[mojca]

I suggested something different, but your proposal is better. Potentially call it os_arch_id to make it more explicit that it's not just about OS version (even though I'm not 100% sure about that). We also need to store somewhere the name to be displayed (10.15, 10.14, ..., 10.6, 10.6/i386, 10.5/ppc; doesn't matter what character is used as a separator, underscore is fine as well).

[mojca]

Should the newly set up builders usually be automatically picked up? (I don't see anything for the new builders being picked up yet.)

[arjunsalyan]

Should the newly set up builders usually be automatically picked up? (I don't see anything for the new builders being picked up yet.)

No, the app won't pick up new builders. This functionality wasn't built, and I also don't think we have a source from where we can get such information (not sure though).

[mojca]

How did you do the first run populating the builders?

In principle you could get the info from API like https://build.macports.org/json/builders?as_text=1 (which would change and become more intuitive with buildbot 2). I didn't find a way to further reduce the amount of data received.

(Then again, we could just as well hardcode the few builders that we have.)

[arjunsalyan]

Even the os_arch_id might require some hardcoding. Or do we generate it using some pattern?

[arjunsalyan]

I suggested something different, but your proposal is better. Potentially call it os_arch_id to make it more explicit that it's not just about OS version (even though I'm not 100% sure about that). We also need to store somewhere the name to be displayed (10.15, 10.14, ..., 10.6, 10.6/i386, 10.5/ppc; doesn't matter what character is used as a separator, underscore is fine as well).

While trying to implement this I felt that the display_name field might remove the need of the os_arch_id. I mean, display_name would be same for 10.8_x86_64 and 10.8_x86_64_legacy, then I don't think we would need a separate key. Later, if the new buildbot setup brings in 10_8_x86_64 type of nomenclature, again we can set display_name for it as 10.8 and all the three will then point to the same os, 10.8.

Please let me know what I might be missing.

[mojca]

While trying to implement this I felt that the display_name field might remove the need of the os_arch_id. I mean, display_name would be same for 10.8_x86_64 and 10.8_x86_64_legacy, then I don't think we would need a separate key.

Yes.

What I meant with os_arch_id could either be a numeric id that resolves to the actual name (via an additional table), or it could be a string. And display_name is in fact a much better name for the column than os_arch[_something].

Later, if the new buildbot setup brings in 10_8_x86_64 type of nomenclature, again we can set display_name for it as 10.8 and all the three will then point to the same os, 10.8.

Yes, that would solve it.

Please let me know what I might be missing.

What you suggested makes perfect sense.

The only requirements are that:

• port health shows just a single entry for 10.8, using the latest build results
• ports.macports.org/port/<name>/builds / Filter based on builder shows just a single entry for 10.8, and when 10.8 is selected, results from both builders show up
• clicking on the hyperlink properly resolves for both the old and the new builder
• (very low priority, something to worry about later) when old builder gets removed (say, when we decide to shut down buildbot 0.8 setup) or when the build "gets out of scope" (for example more than 10k builds old according to the current settings), the links to builds are no longer clickable.

I believe that not doing any change to the existing build tables should work, and just adding more info about individual builder could work, but of course there will be some more table joins needed to display the requested information.

[ryandesign]

What's the status on getting this resolved? Right now the port health indicators are misleading for 10.6-10.8, because they show the last build before the switch to the libc++ workers, which might even have been a build of an earlier version of the port.

[arjunsalyan]

Yes, I am a bit late on this. I did work on this this previously but the solution can be simplified by using only one display_name field. I am hoping to have this fixed by Sunday.

[cjones051073]

Any news on this ? The 10.15 builders are also now available so should also would be good to display the results for them too, as they become available.

[mojca]

The new builders for 10.6-10.8 have already been added, however:

• @ryandesign has disabled the workers (until a bunch of binary archives are cleaned up, and maybe other issues)
• The full history has not yet been imported (this would be somewhat higher or priority list)
• We need to add a new entry for 10.15 now (and of course also fetch full history) so you will only see a very tiny number of builds.

[cjones051073]

Any update on adding the 10.15 build results to https://ports.macports.org/ ? Its a little inconvenient to not to be able to use this site to reference 10.15 build results.

[cjones051073]

Any news ? Just a comment, adding new OS releases is something we will need, about ince a year, so should be something that is easy and quick to do...

[arjunsalyan]

Any news ? The PR is now in a good state and should get merged very soon.

Just a comment, adding new OS releases is something we will need, about ince a year, so should be something that is easy and quick to do...

It is not very difficult right now, but yes, the friction can be reduced. This PR particularly got delayed due to a completely unrelated test starting to fail.

We also thought of automating the process of picking up any new builders, but it was delayed because of an expected deployment of Buildbot 2 and the changes it might bring with it. @mojca Do you have any news about Buildbot 2?

[arjunsalyan]

10.15 has been added and entire build history has also been fetched.

[ryandesign]

Super, thanks!

As for buildbot 2, if it's ready to go, I guess I need to try again to install it on a new vm on the server. I had made an attempt before but gave up when I encountered the postgresql server requirement, because I didn't know which version to install or how I should configure it.

[mojca]

I believe that the main of this ticket has been resolved, but a few other fronts remain open that might warrant opening a new ticket. Like:

1. automatically detecting a new builder when one becomes available
2. stop fetching from old builder if it no longer exists

We only need to do (1) once per year, and in case we switch to a newer buildbot, we'll need to redo the work. So I'm not even sure if we want to fix it right now. We need @ryandesign's feedback about whether (2) is still an issue that needs fixing.

Anything else that I might have forgotten?