Gsoc 18 Project | Collect build statistics

[Mojca Miklavec]

On 30 April 2018 at 18:47, Jackson Isaac wrote:
> On Mon, Apr 30, 2018 at 10:06 PM, Vishnu wrote:
>> Hey
>>
>> Repository names:
>> MacPorts-features?
>> Macportsinfo?
>> Or just simple
>> gsoc18?

No, gsoc18 is a bad name since the idea is to use the project
afterwards as well and I don't like to rename it two years from now.
(We can decide to rename it one month from now, but not once people
start forking it etc.)

> I was thinking about macports-portstatistics or macports-portstats.

Or "macports-portinfo" as something inbetween? I'm somewhat reluctant
about "stat[istics]" because it's about much more than statistics.

>> And also in the long term. Parser would be run only once in forever or say a
>> year.

No way. Parser needs to be run after each commit. Initially it could
be once per hour or so to simplify things and avoid hooks etc., but in
the long term it needs to be run immediately after GitHub notifies you
about the update.

>> And before running the original db must be cleared.
>>
>> And then obvious question arise. What if a new port is added in macports.
>
> You are on a right path I would say. We would want it to update after
> every port is added/updated
> and built.

Indeed, if a new port is added, you need to update the database. More
important: also if a port is removed or if version changes etc.

>> For that i would like to know the mechanics of new port addition.

See one of recent pull requests:

https://github.com/macports/macports-ports/pull/1694/files

This commit will create a new Portfile with four subports
(py-waitress, py27-waitress, py35-waitress, py36-waitress), update a
bunch of existing ports and add a bunch of new subports to existing
Portfiles (py35-paste, py36-paste, ...)

We could at the same time declare a few ports obsolete or delete some.

You get all that info from Portindex (it could be useful if we could
get some kind of "differential Portindex"; I'm not absolutely sure how
port deletions are handled).

>> I think before the new port is added. It is obviously built before right?

No. It is first added. Only once it is added it can be built on the
buildbot (a commit to repository triggers a build on the buildbot).

>> So
>> maybe we can add some code there to update the table with a row when new
>> port is added.
>
> When a port is submitted, it is built by Travis CI and also our
> buildbots,

Travis only builds pull requests, not actually commits.

> which builds
> the port for mac 10.6 to 10.13 versions and gives the build status. We
> would be more
> interested in the status provided by the buildbot.

I would ignore Travis builds for now anyway. It could be interesting
to add pointers to open pull requests for a particular port, but not
right now. Evidently your code needs to first update the database to
get the list of all new ports, information about successful or failed
builds would come later from the buildbot.

> There could be a trigger or a listener which runs whenever a build job
> is initiated and then
> updates the DB on completion. I believe there would be some mechanism
> to know the status
> of each job.

You can access the API from the buildbot to ask for status. But if you
don't have an entry for a particular port first, you might run into
troubles if you'll want to add build results without being able to
reference a port with that name.

> Maybe someone more familiar with buildbot could share some insights ?

In any case it would make a lot more sense to start with tens of
thousands old builds first and only once that is done add the latest
information as soon as it's available. There is a high chance that
things will change if we switch to buildbot version one (which might
happen in the meantime).

Mojca