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
