Re-enable nRF52840 lock example targets in travis

[suryanshup]

-- Download sdk and tools for the nrf52840 lock example target in the
before_install script rather than in the prepare script. This makes sure
that dependancy installation happens only once as we add more
applications in the future for the nrf52840 platform that use the
same dependencies.
-- Enable building nRF52840 Lock Example on Linux and OSX

[gerickson]

It's not clear why the .travis/build_nrf52840_lock_example.sh or .travis/prepare_nrf52840_lock_example.sh are in openweave-core rather than openweave-nrf52840-lock-example.

[gerickson]

It's not clear why the .travis/build_nrf52840_lock_example.sh or .travis/prepare_nrf52840_lock_example.sh are in openweave-core rather than openweave-nrf52840-lock-example.

[gerickson]

It's not clear why the .travis/build_nrf52840_lock_example.sh or .travis/prepare_nrf52840_lock_example.sh are in openweave-core rather than openweave-nrf52840-lock-example.

I realize those two files are now removed with this PR; however, it's not clear why the content is in or should be in this repo.

[suryanshup]

It's not clear why the .travis/build_nrf52840_lock_example.sh or .travis/prepare_nrf52840_lock_example.sh are in openweave-core rather than openweave-nrf52840-lock-example.

I realize those two files are now removed with this PR; however, it's not clear why the content is in or should be in this repo.

@gerickson, the idea here is to make sure that changes going into openweave core don't break the lock example app. This target did exist earlier but was disabled by Jay in commit e509266. I just re-enabled it and cleaned up the scripts a little.
I appended 'lock_example' to the script names to be a little more specific about what is being prepared and built (.travis/prepare_nrf52840.sh to .travis/prepare_nrf52840_lock_example.sh) in case we have scripts for more than one example application on the nrf52840 platform in future.

[gerickson]

It's not clear why the .travis/build_nrf52840_lock_example.sh or .travis/prepare_nrf52840_lock_example.sh are in openweave-core rather than openweave-nrf52840-lock-example.

I realize those two files are now removed with this PR; however, it's not clear why the content is in or should be in this repo.

@gerickson, the idea here is to make sure that changes going into openweave core don't break the lock example app. This target did exist earlier but was disabled by Jay in commit e509266. I just re-enabled it and cleaned up the scripts a little.
I appended 'lock_example' to the script names to be a little more specific about what is being prepared and built (.travis/prepare_nrf52840.sh to .travis/prepare_nrf52840_lock_example.sh) in case we have scripts for more than one example application on the nrf52840 platform in future.

Why aren't we doing that CI in openweave-nrf52840-lock-example?

[jaylogue]

Why aren't we doing that CI in openweave-nrf52840-lock-example?

@gerickson We do. But openweave-nrf52840-lock-example doesn't build when a PR is submitted against openweave-core. In this case, building the lock example within openweave-core, using the submitted code from the PR, gives the author visibility into whether their change is going to break something on that platform. The ESP32 target works the same way.

[jaylogue]

Why are these values exported?

[gerickson]

Why aren't we doing that CI in openweave-nrf52840-lock-example?

@gerickson We do. But openweave-nrf52840-lock-example doesn't build when a PR is submitted against openweave-core. In this case, building the lock example within openweave-core, using the submitted code from the PR, gives the author visibility into whether their change is going to break something on that platform. The ESP32 target works the same way.

I believe we need to find a more scalable solution. The ESP32 target was a acceptable one-off; however, now that we are adding more demo / example integrations, it's time to find a better, more scalable approach.

While it doesn't look like Travis CI has a way to trigger another project to build out of the box the way Atlassian Bamboo did/does, but maybe this hints at a path by which we can effect something similar:

https://hiddentao.com/archives/2016/08/29/triggering-travis-ci-build-from-another-projects-build

[jaylogue]

The linked example doesn't do what we need. In particular, we need the openweave-core build to fail
if one of the examples doesn't build with the proposed commit. I think its also very important that we have the same reporting and control features (e.g. email, log capture, ability to restart a build) as we get with a standard Travis job.

I don't really understand the scale issue. Given that we need to maintain two related, but not identical build actions across each example--one that builds commits against the example project, and one that builds the example project for commits against openweave-code--ultimately I think the mount of support effort is going to be the same.

Granted, the current state of the build/prepare scripts forces us to have two implementations of largely identical behavior. But we should be able to restructure the scripts such that the code can be shared between the two projects. With this done, we might be able to have the openweave-core build pull the build/prepare scripts from the example repos as part of the build process, such that there is only one master copy of the shared scripts.

[suryanshup]

I re-worked the scripts in openweave-core build to pull the prepare script from the example repo as part of the build process, such that there is only one master copy of the shared scripts.

[gerickson]

Approved in concept. I'll let you and @jaylogue iterate on the best way, short-term, to eliminate copy-and-paste among the projects.