Gsoc 18 Project | Collect build statistics

[Rainer Müller]

On 2018-05-11 09:17, Mojca Miklavec wrote:
>> I got the rough idea of the db from here:
>> https://github.com/macports/macports-infrastructure/blob/2129f0cd0eb80f207d2cc62542b65c197733ac51/jobs/PortIndex2PGSQL.tcl#L249
> 
> Sure, you can take this as inspiration for database design, but not as
> your definite source of data. Your definite source of data should be
> PortIndex from the latest git checkout of macports-ports.
> 
>> So is this updated regularly?How?
> 
> I'm not absolutely sure, but I believe the changes are deployed after
> each commit via
>     https://build.macports.org/builders/jobs-portindex

That is correct. The job is using the portindex2postgres.tcl script. The
SQL output is imported using psql into the database.

https://github.com/macports/macports-infrastructure/blob/master/jobs/portindex2postgres.tcl

>>>> On 9 May 2018 at 03:43, Vishnu <vishnum1998 at gmail.com> wrote:
>>>>>
>>>>> I had one doubt.
>>>>> Should i switch the link in heroku account for integration with macports
>>>>> github ?
> 
> I'm not sure what is it that you are asking. If Heroku need special
> priviliges on GitHub (what permissions are required?), it might be
> best to create an additional user on GitHub for now. Can you provide
> some pointers? It's pointless that I theoreticise about the options
> before I know what is required.

We can also provide GitHub API tokens that belong to the macportsbot
user, if that is what you need. You would need to tell us the required
scope for the tokens.

>>>>> Because i think then you need to give accesss to heroku of your account.
>>>>>
>>>>> I think it would be wise for me to do the commit update in my local
>>>>> repository itself..
>>>>>
>>>>> Once every 2 weeks or something ill push all the changes to macports
>>>>> repository.
>>>>> Do comment .What should be done?
> 
> I wanted to suggest that the app would be developed either in a
> separate branch or in your fork of repository (not in master branch,
> please!), and then you would make pull requests on regular basis and
> we would review the pull request and make sure that any code that ends
> up in repository has been fully reviewed / tested.
> 
> If you commit everything (including tests) straight to the master
> branch of the main repository, it's more challenging to track which
> code reviews have already been taken into account and which ones were
> not. You should not make giant pull requests anyway (ideally you would
> make a PR on approximately daily basis or at least once per week in
> case you need to figure out a number of things and code is not yet
> ready; making one giant PR every two weeks or - god forbid - once per
> month or only at the end of GSOC might cause too many troubles).

Push your code often, not just every two weeks. Pushing early gives
mentors more time to review your code before calls. It also makes it
easier for the mentors to track your progress and also for yourself.

The problem with pull requests would be that GitHub cannot handle
dependencies between pull requests. A daily pull request will probably
not work out, unless mentors also approve and merge the pull request
within a day...

Rainer