When you’re trying to build grails for a CI server (I’m using Hudson), it’s recommended that you don’t check certain things into subversion. To restore those things properly in the environment, you should run “grails upgrade.” The problem, of course, is that grails upgrade requires some interactive input asking if you’re willing to overwrite files.
Apparently, you can just go grails upgrade -force and it will do it without interactive input. So, your ant task looks like this:
<!-- =================================
target: upgrade
================================= -->
<target name="upgrade" description="--> Runs grails upgrade to restore stuff after svn checkout">
<exec executable="${grails}" failonerror="true">
<arg value="upgrade -force" />
</exec>
</target>
5 comments ↓
I rescind this grails tip. Tried it on the command line on both windows and linux, and it works great. But, throw it into hudson CI (and make it a depends target of a target like “hudson”), and it seems to ignore the -force part of things. If anyone has any tips, let me know.
OK, I figured out a way that works for me:
(1) Set up hudson to just check out the files
(2) Run a build (it should succeed, it’s just checking stuff out)
(3) Manually, go into the directory and run “grails upgrade -force”
(4) Set up the rest of hudson (with the batch file). As long as you have the “update” checkbox checked, grails will always be “upgraded.” My batch file is actually 2 files:
set GRAILS_HOME=D:\devenv\grails-1.0.3
set ANT_HOME=D:\devenv\apache-ant-1.7.0
set Path=%Path%;%GRAILS_HOME%\bin;%ANT_HOME%\bin
cd myproject
ant hudson
set CATALINA_HOME=D:\devenv\tomcat6
set Path=%Path%;%CATALINA_HOME%\bin
cd myproject
copy *war D:\devenv\tomcat6\webapps /Y
(5) I made the hudson target as well, and it depends on clean, [custom ant target to rebuild from other jars], war, test, doc. I customized the test target to run test-app-cobertura and run-webtest.
(6) Set up Hudson to look for the junit xml files so it can graph your testing results. I set it up for hourly builds and polling SCM hourly as well.
I experienced the same thing. But I found another way to trigger this to work.
You can set the properties “grails.upgrade.warning” and “grails.src.encoding.warning” to “y” (well, actually, anything other than “n”) when executing the “grails upgrade” script. It will skip over the input requests, since the properties are already set.
That’s a great tip Justin. I’ll be trying that out soon.
Justin’s tip worked awesomely. I just set those two properties in application.properties, and it works like a charm. Thanks!
Leave a Comment