[Fuego] [PATCH 7/7] kernel_build: add multiple deploy options

[Daniel Sangorrin]

> From: Tim.Bird at sony.com <Tim.Bird at sony.com>
> OK - I've applied the patches, and then did a small refactoring patch on top.
> I decided to go with the following deploy_methods: log_dir, local_dir, board_dir
> and to support an optional deploy_path (for local_dir and board_dir, with defaults
> for each).
> 
> Please try it out and let me know if it works for you.  I successfully built in my docker
> image.  Kernel's built on my other boards, but then there were issues finding the
> kernel image (I likely hadn't set some needed variable).

Thanks, I am testing it. 

> One other thing I noted: This test should always perform its test_build phase,
> as that's the point of the test.  I ended up doing another commit on top
> that sets the "Rebuild" variable, so that Fuego doesn't skip the build.
> I'm not sure how this interacts with unpacking code into the existing directory.
> Possibly this should be more aggressive and remove everything from the
> build directory before proceeding with the build.
> 
> If this test is used as part of a broader set of testing actions, then configuring
> it to skip the build if the kernel hasn't changed would make sense.  So this may
> need to be re-thought when that happens.  Let me know if doing a forced rebuild
> goes against your use cases for this test.

I was using ftc's --rebuild flag to clone and build from scratch on each run. Kernel repositories that may be rebased need to be cloned and built from scratch. However, having to clone the kernel repository on every run is time consuming. For kernel repositories were rebasing is not supposed to occur we can do better. The test was supposed to git-pull the latest changes if the Rebuild flag was 'false'. Unfortunately, I just noticed that the git pull is not effective now that I moved it from test_run to test_build. 
I have prepared a quick fix and sent you a patch for discussion.

> I basically agree with all of this.  Creating a script that calls ftc in order sounds like
> the easiest solution.  Trying to manage ordering with a declarative syntax is,
> IMHO, harder for users to understand.
> 
> It would be nice if we could just do something simple like the following:
> function test_run {
> 	ftc run-test -b $BOARD_NAME -t Functional.kernel_build
> 	ftc run-test -b $BOARD_NAME -t Functional.kernel_provision
>                 ftc run-test -b $BOARD_NAME -p testplan_myproject
> }
> 
> Maybe we already can?
> 
> In this case, the absence of a board locking at the 'ftc' level is actually helpful.
> This would all run as a single Jenkins job (if launched from a job), so Jenkins
> node locking would not get in the way.

Wow, we will need to differentiate when to lock and when not to.

Thanks,
Daniel