PCTCompile / PCTCompileExt - failOnError behavior

[GoogleCodeExporter]

Hi,

I found that failOnError behavior does what it says in the documentation ("If 
task should end just after a failed file compilation"), but I would rather 
prefer to behave like it does say with javac task 
(http://ant.apache.org/manual/Tasks/javac.html - "Indicates whether compilation 
errors will fail the build; defaults to true").

In the PCTCompile case, setting failOnError to false does make it continue, but 
eventually the task will fail, where with Javac it will continue, but it won't 
fail the task - it will just print an error message saying "[javac] Compile 
failed; see the compiler error output for details.".

In my case, I'm writing a build task that eventually will send an email (using 
the mail Ant task) regardless of the compilation results, but as the build 
fails it won't continue and won't send the email.

I think I found the code in pctCompile() procedure in pctBgCompile.p that 
controls whether the task passes or fails - ASSIGN opOK = (compNotOk EQ 0) - 
but I cannot see how the failOnError can be accessed at that level.

Thanks,
Dan

Original issue reported on code.google.com by dan.dra...@gmail.com on 30 Jul 2011 at 11:08

[GoogleCodeExporter]

Seems OK for the behavior. But you should avoid sending an email using Ant for 
failed compilation. Use a Continuous integration tool like Jenkins ( 
http://jenkins-ci.org ) to handle that (and much more).
Have a look at http://riverside-software.fr/FBATCI.pdf for continuous 
integration with OpenEdge. I'm doing this presentation in Amsterdam for the PUG 
challenge in November.

Original comment by g.quer...@gmail.com on 1 Aug 2011 at 6:39

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Hi Gilles,

It gets a bit more complicated - our application consists of 4 modules with 
slightly different PROPATHs and separate source locations, that we used to 
compile together and review later one.

I have broken down the modules separated in separate PCTCompileExt sections 
part of the same task, but if one of them fails it won't compile the other one. 
I guess my thinking was to go through all together and then use tests for 
separate resultProperty-ies and fail the whole task.

I could have them in separate tasks and build them separately, in a way I agree 
it's probably better - but add on top of that 3 different database platforms 
(PROGRESS, ORACLE and MSSQL) and that makes 12 separate builds / emails to 
review instead of say 3 (per platform) and maybe you can see where things might 
get a bit harder to manage...

Thanks,
Dan

PS: Thanks for the suggestion, I had the Jenkins / Hudson CI in mind when I 
first saw your project and it's a great idea, just set that up yesterday and 
have it send the email instead of doing through the script. Nice tool alright.

Original comment by dan.dra...@gmail.com on 4 Aug 2011 at 8:35

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I've setup such a build a few years ago and started like that (monolithic build 
for every combination), before the rise of continuous integration tools. But 
it's really far easier to have a simpler build with parameters (like db 
connection, progress version, and switch for MSS/ORA/ODBC) and multiple jobs on 
the CI server. This way, you can track exactly which version fail (what if the 
build fails for Oracle, then you correct the bug, and have another bug for MSS 
? you have to wait longer...) and you can use Hudson slaves to build your 
software on multiple platforms to have faster results.

And one thing to keep in mind with Hudson : never send an email for successful 
builds! You should just track failures.

Original comment by g.quer...@gmail.com on 11 Aug 2011 at 3:18

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I used the opportunity to introduce PCT as part of the release process, so 
that's all together - but no I did write the script in such a way to separate 
platforms, it was just bunching all modules for a platform together, so I had 3 
separate targets per platform in CI server.

It's not important, it's all done now, I intend for nightly differential builds 
to use separate module tasks, and see how that goes. If I need a customisatios, 
I'm getting familiar with the sources and Mercurial (a pain in the neck to 
adjust from SVN/CSV :-) and if I need to I will make a customisation in my 
clone and promote for review.

Btw, thanks for introducing the numThreads in PCTCompileExt, that was quite 
helpful as we have about 5000 sources and it was taking hours to compile over 
the network (we keep the sources on a network drive), and that was reduced 
dramatically to 1.5h per platform using 5 threads.

Thanks for the tip, you're right - success emails just to a couple of people 
watching the process over, and then all developers for failures.

You can close the ticket if you want, it's all fine for now, thanks.

- Dan

Original comment by dan.dra...@gmail.com on 13 Aug 2011 at 8:49

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Good to see numThreads is useful. And for Mercurial, check http://hginit.com 
and especially the Subversion reeducation chapter. It will teach you how to 
deal with the differences between SVN and HG. 

Original comment by g.quer...@gmail.com on 15 Aug 2011 at 12:07

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****