Autobuild CLI binary

[naorlivne]

There should be a full CI\CD (TravisCI based most likely) that autobuilds the CLI binary and pushes it to the github repo whenever an update is made to it.

[jakobpederson]

I was attempting this and had some questions. I've got a .travis.yml file and had a placeholder tests.py file set up, but I don't understand the "autobuilds the CLI binary and pushes it to the github repo", because at the moment it seems like travis only triggers on a PR, not an update. Is the goal to have it trigger a PR anytime a push is made?

[naorlivne]

Hi @jakobpederson

First let me thank you for stepping up and helping with this issue.

My thought process when opening this issue was that currently deploying a new version is a matter of me having to manually run pyinstaller -F nebulactl.py inside the repo root folder to create the nebulactl binary in the dist/ folder, being a binary we can't have any contributor build it himself for every contribution for security reasons (& besides I'm pro automation) so I wanted to leverage Travis to automate that step.

As to what way Travis will push the binary back to GitHub is something I leave open for the contributor (in this case you) to decide on, it can be either a script which runs a git push, it can open another PR with the latest version binary or it can also be something like using Travis built in deployment release - https://docs.travis-ci.com/user/deployment/releases/ - just about everything will be better then the current manual build\push way of deploying a new binary.

It may very well be that Travis will need to be reconfigured to trigger on updates rather then just PR in order to achieve that, if you come anything where you require changes on Travis that are outside the scope of it's .travis.yml feel free to drop me a line with what changes are needed.

Having a place holder for running unit\smoke tests in place is also a good idea, I had a look at your PR before closing it & it seems like a great start & If you feel like reopening it & changing the python version to "2.7" (which is what nebula is built on) I see no reason not to merge it as is as the first step in resolving this ticket.

EDIT:
https://blog.fossasia.org/push-your-apk-to-your-github-repository-from-travis/ - seems like a good way of doing it as it both solves the loop that would be caused by having Travis push to git thus triggering another Travis run & it's rather simple to implement in a fully automatic way... the blog post is about pushing APK so obviously some changes will be needed but the idea behind it holds true.

More info about having Travis skip the CI of a push can be found at https://docs.travis-ci.com/user/customizing-the-build/#skipping-a-build

[jakobpederson]

Hey @naorlivne,

Thanks for getting back to me! I really appreciate these links. I'll give it a shot and see if I can get something working.

Thanks!
Jake

[naorlivne]

Hi @jakobpederson - not sure if you got stuck at this task or forget or just busy but wanted to let you know I changed the unittest their own folder & that travis now also starts a Nebula manager to run future tests against as part of the CI tests.

[jakobpederson]

Hey @naorlivne, yeah I'm sorry, I ended up having to do a lot of traveling and got really distracted. I think what I had would probably work but I'll take a look at the changes tomorrow. Thanks! Jake

…

On Thu, Jan 17, 2019 at 6:09 AM naorlivne ***@***.***> wrote: Hi @jakobpederson <https://github.com/jakobpederson> - not sure if you got stuck at this task or forget or just busy but wanted to let you know I changed the unittest their own folder & that travis now also starts a Nebula manager to run future tests against as part of the CI tests. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYXpBDlQaxyeCicn6yUYLw0OUAx7_0mBks5vEGf4gaJpZM4Pp6xl> .

[naorlivne]

No need to apologize, being busy & distracted is my usual state so I get it.