These are chat archives for whereat/contrib

4th
Apr 2016
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 02:56
@aguestuser where is the mailing list? would like to follow that discussion / help out
aguestuser
@aguestuser
Apr 04 2016 02:57
This message was deleted
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 02:58
re homu, if you want to see what it looks like, take a look at some of our PRs, eg nix-rust/nix#310 and nix-rust/nix#335 and
woop subscribed
re the big questions marks
(1) for signed packages / deploying: is there a command line flow for this on the app store platforms? I have no experience with apple or google stores
but either way, you'd have to be comfortable with your CI provider having your private key
well not really
I guess you could have your own server that accepts post-build webhooks
but you'd still have to have an online server with your private key to do that
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 03:04
not sure about the threat model, but I could imagine you not wanting your signing key to be online
aguestuser
@aguestuser
Apr 04 2016 03:10
agreed!
Travis has some sort of provision for encrypting sensitive data and/or environment variables: https://docs.travis-ci.com/user/encryption-keys/
back in the day, we'd also been looking at ansible vault: http://docs.ansible.com/ansible/playbooks_vault.html
at the end of the day, it might just be that the actual step of signing and publishing might have to happen on someone's (likely my) laptop. but while we're in the analysis phase for this work, it seems worth looking into whether one platform or another's capabilities in this area are better or worse.
also, thanks for sharing the rust stuff. just about everything about that project is SUPER interesting. :D
FWIW: here is a blog post i turned up on managing the whole build/deploy process to the play store via Travis (two years old): https://droidconin.talkfunnel.com/2014/1311-push-to-play-a-full-ci-implementation-for-android-
aguestuser
@aguestuser
Apr 04 2016 03:16
(clearly i never got to the part of reading that post where i actually tried to find the talk! seems hard to find!)
here's an example of signing and publishing an .apk using jenkins: https://www.bignerdranch.com/blog/continuous-delivery-for-android/
^-- the role of the pipeline architecture in making this possible (build produces artifact, next step signs the artifact, next step publishes it) is perhaps an argument for trying to recreat the setup he used on jenkins in go-cd?
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 04:24
yeah I've used the encryption to set up appveyor and travis to make binary releases on github, which needed a github API token
I think that signing and publishing locally is a good place to start
I'll take a look at those two posts to get an idea
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 04:38
also re pipeline, if it's linear you can achieve it with a script just as well. I think the pipeline stuff gets more necessary when you have multiple artifacts that need to be tested and released together
aguestuser
@aguestuser
Apr 04 2016 14:42
gotcha. arguably we might want to do that with new releases of the mobile client and the server (3 different artifacts)? and if we wind up having some sort of key server (necessary for a lot of key exchange protocols like safe slinger or if we decide to use axolotl for encrypted messaging, then we'd have as many as 5 different artifacts we might want to re-build and integration test any time one of them was updated?
aguestuser
@aguestuser
Apr 04 2016 14:54
better link to axolotl: https://open-whisper-systems.readme.io/
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 15:41
is the protocol changing such that you need lockstep versions? if not I don't think you really need a pipeline
what I meant by multiple artifacts is if you had a multi-component service where you needed to test a "release" at a higher level than individual components
since you can't rely on users to upgrade promptly, I think that doesn't fit here?
never mind
reading comprehension fail
if you do have a key server or something then I think you're right
cool links!
aguestuser
@aguestuser
Apr 04 2016 22:58
hey all. @alxmrtn and i did a deep dive on CI shopping today and sided (for now) with concourse. here's why.
(please feel free to pipe up if you think we got something wrong! :smile: )
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 23:51
ooh exciting
aguestuser
@aguestuser
Apr 04 2016 23:51
yeah! playing with the new toyzzz!
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 23:51
any chance I can get in on setting it up?
aguestuser
@aguestuser
Apr 04 2016 23:52
heck yeah!
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 23:52
woot
aguestuser
@aguestuser
Apr 04 2016 23:52
(to the extent we can make that work remotely...)
we've been working through the (excellent!) docs this evening.
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 23:52
yeah.. not sure what your set up is over there...
nice
it's from pivotal so I figured it would work well
also while it was "just released" there are presentations of it from a year ago
aguestuser
@aguestuser
Apr 04 2016 23:53
(it's the sort of thing they'd be picky about!)
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 23:53
which I have on my to-watch list
aguestuser
@aguestuser
Apr 04 2016 23:54
we did the hello world this afternoon (so easy! and pretty!) and are going to flight school tomorrow.
Kamal Marhubi
@kamalmarhubi
Apr 04 2016 23:54
nice
aguestuser
@aguestuser
Apr 04 2016 23:56
first card we're picking up is running tests on github PR's, which will give us a chance to test our hypothesis that it's worth it vs. travis: whereat/whereat-ci#1