Using curl to install CQ packages

CQ5 has a very good tradition of exposing APIs, which are accessible by simple HTTP (in some cases even RESTful APIs). This allows one to access data and processes from external and is also a good starting point for automation.

Especially the Package Manager API is well documented, so most steps to automate deployment steps really start here. A typical shell script to automate package installation might look like this:

ZIP = directory / to / the / package - 1.0.zip

FILENAME = `basename $ZIP`

CURL = curl - u admin: admin

HOST = http: //localhost:4502/crx/packmgr/service/.json

 $CURL - s - F package = @ZIP - F force = true $HOST ? cmd = upload

if test $ ? -ne 0;

echo“ failed on upload "

fi

$CURL - X POST - s $HOST / etc / packages / mypackages / $FILENAME ? cmd = install

if test $ ? -ne 0;

echo“ failed on install "

fi

As you see, it lacks any kind of sophisticated error handling. Introducing a good error handling is not convenient, as curl doesn’t return the HTTP status as a return code (but just if the request itself has been performed successfully), so you have a parse the complete output to decide if the server-side returned an HTTP 200 or something else. Any non-seasoned shell-script-developer will probably just omit this part and hope for the best …

And even then: When your package installation throws an error during deserialization of a node (maybe you have a typo in one of your hand-crafted .content.xml files), the system still returns an http 200 code. Which of course it shouldn’t.
(The reason for the 200 is, that the code streams the installation progress on each node and that the decision for the status code has to be done before all nodes are imported into the repository. Therefore the need for an internal status, which is one of the last lines of the result. Thanks, Toby for this missing piece!)

And of course, we still lack the checks if embedded bundles are starting up correctly …

So whenever you do such light-weight deployment automation, be aware of the limits of it. Good error handling, especially if the errors are inlined in some output, was never a primary focus of shell scripting, and most of the automation scripts I’ve seen in the wild (and written myself, to be honest) never really cared about it.
But if you want to have it automated, it must be reliable. So you can focus on your other work, and not on checking deployment process logs for obvious and non-obvious errors.

On AEMHub I will talk about the importance of such tools and why developers should care about such operation topics. And I hope that I can present the foundations of a small project aimed at proper CQ deployment automation.

Source: https://cqdump.wordpress.com/2014/03/10/using-curl-to-install-cq-packages-and-why-it-isnt-a-good-idea/