Issue 29663680: Issue 6220 - add travis-ci configuration for adblockpluscore (Closed)
Descriptiononly linux and osx
Patch Set 1 #
Total comments: 4
MessagesTotal messages: 8
Forgot to leave comments. https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml File .travis.yml (right): https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml#newcode1 .travis.yml:1: language: cpp The language is cpp because it will simplify it when we start to compile emscripten code for native applications. https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml#newcode12 .travis.yml:12: - nvm install 8.9.4 current latest LTS, For the beginning IMO it's enough, however we should actually test against several versions, e.g. the versions of V8 which are used in chrome browsers which supported by our extension.
Same with this one, could you review instead of me Tristan?
Hey there, sorry for the late reply. Please find the comment below. https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml File .travis.yml (right): https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml#newcode22 .travis.yml:22: email: false Do we not want to be notified about failed builds? Also, FWIW we could add some sugar and notify #adblockplus about succeeded builds ;)
https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml File .travis.yml (right): https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml#newcode22 .travis.yml:22: email: false On 2018/01/17 12:41:39, tlucas wrote: > Do we not want to be notified about failed builds? Just would like to precise that it can be configured whether it's for failed builds or even always. > Also, FWIW we could add some sugar and notify #adblockplus about succeeded > builds ;) This looks attractive actually, perhaps we should add it, I modified the issue description. IMO we should keep it silent for the beginning until we see that it is working smoothly and see that we really need such information. I have some experience with such notifications, usually e-mail notifications become a spam pretty soon, so I would propose to disable them and drop a message in IRC channel. In addition we should take into account the actual workflow, unfortunately we don't push too often to the main repository, and we are more or less aware when it happens (at least I'm notified in IRC by corresponding keywords) and can track the CI status, on the other hand the default configuration should not bother IMO us nor the author of changes. Let's say I am a third party person (or even I'm who I'm) and want to contribute, in order to do it I fork the repo, make some changes and before sending it to codereview I run CI for the fork, and this CI should not send any e-mail to anybody but me (if I really want it) nor send anything to IRC.
On 2018/01/17 14:25:31, sergei wrote: > https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml > File .travis.yml (right): > > https://codereview.adblockplus.org/29663680/diff/29663681/.travis.yml#newcode22 > .travis.yml:22: email: false > On 2018/01/17 12:41:39, tlucas wrote: > > Do we not want to be notified about failed builds? > Just would like to precise that it can be configured whether it's for failed > builds or even always. > > Also, FWIW we could add some sugar and notify #adblockplus about succeeded > > builds ;) > This looks attractive actually, perhaps we should add it, I modified the issue > description. > > IMO we should keep it silent for the beginning until we see that it is working > smoothly and see that we really need such information. I have some experience > with such notifications, usually e-mail notifications become a spam pretty soon, > so I would propose to disable them and drop a message in IRC channel. > > In addition we should take into account the actual workflow, unfortunately we > don't push too often to the main repository, and we are more or less aware when > it happens (at least I'm notified in IRC by corresponding keywords) and can > track the CI status, on the other hand the default configuration should not > bother IMO us nor the author of changes. Let's say I am a third party person (or > even I'm who I'm) and want to contribute, in order to do it I fork the repo, > make some changes and before sending it to codereview I run CI for the fork, and > this CI should not send any e-mail to anybody but me (if I really want it) nor > send anything to IRC. Sounds reasonable to me - LGTM
kzar, I would like to land it, I think it will grow and shaped later no matter what we do with emescripten, do you find something critical here?
Well I don't have any experience configuring Travis but I can't see anything obviously wrong. Happy for you guys to push it whenever you're happy with it really, you both have more of an idea about this than me. 
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
