Re: [gentoo-dev] Continuous integration on GURU

[Andrew Ammerlaan]

On 22/04/2021 14:39, Agostino Sarubbo wrote:
> On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote:
>> Well, I suppose scanning the dev branch would be preferable over
>> the master branch.  In reality, they are usually only a few hours apart
>> but it might be useful to know of new breakage in dev before it's merged
>> to master.
>>
>> It would be ideal if you could do a switch when master and dev are
>> in sync, and just copy the state from master.
> Hi,
>
> I think that your approach could be generally valid but for this use case I'm
> against because of the following:
>
> 1) The approach is valid in cases like our github PRs and the bot that
> approves the commit. In this case, who moves the commit between branches does
> not know if the scan has been done or not.
>
> 2) I don't see the reason to scan against something that we don't know if will
> be the same in master branch
>
> 3) We are not doing a similar approach for ::gentoo so I don't see why do this
> for GURU since, after all, it is an overlay
>
> 4) Packages in master are supposed to be tested at least from 2 different
> people (who made the commit in dev and who moves the commit to master) so it
> means less bugspam

Well, not quite, packages in master have been manually/visually checked 
for obvious (QA) mistakes and have been automatically checked by 
repoman/pkgcheck. In principle the role of the Trusted Contributor is 
first of all to ensure that no malicious commits make it into the master 
branch, as described on the wiki[1]. In practice this means that we also 
do basic QA checks and look at the repoman/pkgcheck results, since we 
are looking at the commit anyway. We do not actually run emerge on the 
ebuild, back in the early days I used to do that, but the amount of 
commits has grown enormously and it is no longer practically possible to 
do this (and here is where the tinderbox comes in handy).

Furthermore, as per [1] we are not supposed to postpone a merge just 
because a commit has QA issues, fails to build or whatever. The only 
situation in which we do not merge a commit, is if it is malicious. QA 
issues or obvious mistakes are reported back to the author, or fixed 
immediately, but they do not disqualify a commit for merging to the 
master branch.

On the matter of running the tinderbox on the master branch or the dev 
branch, I am undecided. It makes sense to do the checks as soon as 
possible and to fix things before they reach the master branch. On the 
other hand there are sometimes very big issues (missing dependencies and 
such) and I am not sure how the tinderbox will behave in these cases. 
Filing bugs for things which the Trusted Contributors can see in 
repoman/pkgcheck (such as missing dependencies) is a waste of cpu power, 
and only serves to increase the number of emails, so if the tinderbox 
would also file reports for these issues I would advise to run the 
tinderbox only on the master branch. (Then there is also the matter to 
consider that in theory the dev branch could contain malicious code, 
whereas the master branch is guaranteed to be free of this. So if the 
tinderbox runs on the dev branch, then in theory a hypothetical 
malicious commit might break the tinderbox.)

Tl;dr Commits are checked, not actually tested.

[1] 
https://wiki.gentoo.org/wiki/Project:GURU/Information_for_Trusted_Contributor

>> One more thing: might be a good idea to consider splitting some
>> of the 'big' trackers (like CFLAGS) between Gentoo and GURU.  I think
>> solving these bugs in GURU has lower priority than in Gentoo.
> I think that trackers like CFLAGS/LDFLAGS are here to track how many packages
> have the problem. I don't see it like (for example) the gcc-porting tracker
> that gives the idea about how much packages need a fix and how much packages
> need to be last-rited
>
>
> Agostino
>
>
>