These are chat archives for whereat/contrib

3rd
Apr 2016
Kamal Marhubi
@kamalmarhubi
Apr 03 2016 02:46
:wave:
reading ^^^ a bit
@aguestuser if your main requirements are pre-merge review, you can get that with travis + homu
homu.io
there we go
it's an integration bot that came out of the Rust community
Kamal Marhubi
@kamalmarhubi
Apr 03 2016 02:53
I set it up for a project I'm a maintainer on. You leave a comment like "@homu r+" to accept a PR
it creates a merge commit against current master, tests the result of the merge, and only merges to master if it passes
I've set up building artifacts on tagging for another project with travis
so you can get some of this stuff for free with no ops burden if you want to
on the other hand, I understand you have some desire for more strongly trusted infrastructure
aguestuser
@aguestuser
Apr 03 2016 06:40
hi @kamalmarhubi! that looks like a very painless workflow! does feel like travis is the main frontrunner right now. from reading the "vs" post you shared, it seems to me the close second is go-cd, but only if we (1) care about pipelines (which it's not clear to me we do, since we don't really have artifacts that depend on one another), (2) care about self-hosting a lot (right now we only care about it theoretically since it's not an immanent part of our threat model), and (3) on the off chance that deploying a server for integration testing might be easier if we've got a go server orchestrating the provisioning of an integration testing server (or exploratory testing server, etc...) after basic unit and functional/ui tests pass...
overall, the big question marks for me across all platforms are (1) how the heck do we make a signed package and deploy it to the various mobile app stores, and (2) how do we provision 1 box that can run all tests for the react-native app (which likely will have tests in JS, Java, and Objective C). Sadly facebook's repo isn't terribly instructive in this regard, as they seem to be using travis, circle, and buck for their build... https://github.com/facebook/react-native
aguestuser
@aguestuser
Apr 03 2016 06:48
In any case, feels like the issue might be nuanced enough to warrant more long-format discussion on the mailing list. Going to sit down Sunday or Monday and try to write down all of the user stories that compose the sequence that gets us to a workable build, extract some requirements from that, and put them to the group for a little pro/con decisionmaking. @alxmrtn and i are putting in a big push next week to get as much of the CI pipeline in place as we can, so hopefully that discussion can be a good place for folks to weigh in and guide the work as we move forward...
ziggy
@aepyornis
Apr 03 2016 16:12
I never ended up getting that testId to work; so I bunkered down and learned XPATH. Submitted the pull request for encryption/decryption text box....try it out!
aguestuser
@aguestuser
Apr 03 2016 20:35
yay! great perseverence, @aepyornis ! wrote up some comments here: https://github.com/whereat/whereat-native/pull/25#issuecomment-205048106
would appreciate other people's input as to whether we should address the issues i brought up before merging or work them into subsequent tickets. :D
also: someone with a mac is gonna have to roll up their sleeves at some point soon and figure out this whole testId jawn: it's the only way we can write functional tests on iOS, and the functional tests are the only way we can (automatically) test whether new features like this that work on the android side break the iOS app or not.
as an added motivation to the CI discussion: remote automated functional tests are the only way (I can think of) that people with linux laptops like me and ziggy can submit pull requests like this and allow the team to confidently merge them without having to pull the code down and run the iOS tests themselves! three cheers for figuring out CI!