On 2/9/19 12:47 PM, Schanzenbach, Martin wrote:
>> I also do
>>  not quite see whatever you want to do with the GitLab CI that
>>  could not properly handle the bigger repo we have today
>>  (especially given that Buildbot is today fine with it)
> It is not a CI issue. It is a build and testing issue (which is automated 
> though the CI but that is secondary).
> What do you mean buildbot is fine with it? _I_ as a developer am not fine 
> with buildbot being triggered to run make check on gnunet.git because a gtk+ 
> widget changes.
> I am also not file with buildbot being blocked for half an hour because a 
> line in gnunet-service-conversation changes.
> It is very simple separation of concerns.
> 

But isn't that simply a question of writing the triggers correctly? I
mean, we don't actually re-build gnunet.git because of Gtk+ changes
(smokescreen), and I don't see why one couldn't teach the CI to not test
transport/ when only conversation/ changed.

And I agree that some of our tests simply take too long, but that's more
of a question of fixing the test logic (and allowing more of it to run
in parallel) for me.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
GNUnet-developers mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Reply via email to