test-patch to sanity verify the build tool

[Mike Drob <md...@apache.org>]

Hi Yetus devs,

Looking for a bit of guidance on how to properly setup modules for test-patch executions.

At my day job we were using Yetus for a maven project and accidentally broke our test patch job by accidentally misconfiguring the path to maven binaries. This didn't get caught because the patch was changing the personality file but no java source was changed. So when we tried to be "smart" and "efficient" we skipped all the actual maven steps and didn't catch that the binary was broken until the next patch failed in mysterious ways.

Does it make sense to always run a maven goal? mvn_install? mvn_deps? Not sure what we would actually need. Is this something that we should address in our personality or is this generally useful?

Possibly related - we're still on 0.4.0, so if this same behavior has been fixed by default in a newer version that's an easy solution too.

Thanks,
Mike

Re: test-patch to sanity verify the build tool

[Mike Drob <md...@apache.org>]

On 2018/02/11 19:07:56, Allen Wittenauer <aw...@effectivemachines.com> wrote: 
> 
> > On Feb 11, 2018, at 10:28 AM, Mike Drob <md...@apache.org> wrote:
> > 
> > Hi Yetus devs,
> > 
> > Looking for a bit of guidance on how to properly setup modules for test-patch executions.
> > 
> > At my day job we were using Yetus for a maven project and accidentally broke our test patch job by accidentally misconfiguring the path to maven binaries. This didn't get caught because the patch was changing the personality file but no java source was changed. So when we tried to be "smart" and "efficient" we skipped all the actual maven steps and didn't catch that the binary was broken until the next patch failed in mysterious ways.
> 
> 	Did the personality set the maven location?  That's a little unusual.  Although I guess if Docker is always used and there is no need to run on anything but Linux, then the maven location could easily be a fixed point.

I misremembered the original change, but was not too far off. Our Jenkins job runs a script from the repo that sets up a bunch of env stuff and then calls test-patch. The change was to the script, not the personality but gives essentially the same symptom.

> 
> > Does it make sense to always run a maven goal? mvn_install? mvn_deps? Not sure what we would actually need. Is this something that we should address in our personality or is this generally useful?
> 
> 	For big projects, always doing a 'real' maven command is super expensive.  It probably wouldn't be too bad to add a 'mvn -v' to maven's precheck code though.
> 

Yea, this matches what I was thinking. There's a reason that we 

> > Possibly related - we're still on 0.4.0, so if this same behavior has been fixed by default in a newer version that's an easy solution too.
> 
> 	YETUS-508 (added in 0.5.0) might have fixed it.  In 0.7.0, I just ran a fake patch that only modified a text file with --mvn-cmd=/bin/notreal as an option.  It failed with:
> 
> 	| -1 | maven | 0m 04s | ERROR: maven was not available. 
> 
> 	in the prechecks phase. That precheck specifically detects if the given file exists and is executable. It does not check functionality.
> 

I was thinking about this and realized that YETUS-510 (which I filed) probably helps in 0.6.0 too.

Guess we really need to upgrade! Thanks!

> 

Re: test-patch to sanity verify the build tool

[Allen Wittenauer <aw...@effectivemachines.com>]

> On Feb 11, 2018, at 10:28 AM, Mike Drob <md...@apache.org> wrote:
> 
> Hi Yetus devs,
> 
> Looking for a bit of guidance on how to properly setup modules for test-patch executions.
> 
> At my day job we were using Yetus for a maven project and accidentally broke our test patch job by accidentally misconfiguring the path to maven binaries. This didn't get caught because the patch was changing the personality file but no java source was changed. So when we tried to be "smart" and "efficient" we skipped all the actual maven steps and didn't catch that the binary was broken until the next patch failed in mysterious ways.

	Did the personality set the maven location?  That's a little unusual.  Although I guess if Docker is always used and there is no need to run on anything but Linux, then the maven location could easily be a fixed point.

> Does it make sense to always run a maven goal? mvn_install? mvn_deps? Not sure what we would actually need. Is this something that we should address in our personality or is this generally useful?

	For big projects, always doing a 'real' maven command is super expensive.  It probably wouldn't be too bad to add a 'mvn -v' to maven's precheck code though.

> Possibly related - we're still on 0.4.0, so if this same behavior has been fixed by default in a newer version that's an easy solution too.

	YETUS-508 (added in 0.5.0) might have fixed it.  In 0.7.0, I just ran a fake patch that only modified a text file with --mvn-cmd=/bin/notreal as an option.  It failed with:

	| -1 | maven | 0m 04s | ERROR: maven was not available. 

	in the prechecks phase. That precheck specifically detects if the given file exists and is executable. It does not check functionality.