Page History

...

The CI Server has limited memory, and the AIR SDKs have grown in size such that if an AIR SDK changes, the CI Server will hang while computing the new MD5.  You can tell the MD5Checker job is hung because the progress bar in the Jenkins UI will be red.  If you see this, manually cancel the Jenkins job so the other jobs can run, then run MD5Checker locally and update the sdk-installer-config-4.0.xml file as described above. 

You may also notice that some times there are several "build failed" emails followed by a "build fixed" then later, more "build failed" emails.  I'm not quite sure why this happens, but my theory is that things like the AIR SDK is published on a CDN and CDNs are essentially mirrors behind the same URL.  It takes time for these files to propagate to all mirrors, and during that time, different runs of MD5Checker will pull the new version and fail and sometimes the old version a succeed.  I've found that after a day or two, we get pretty consistent failures and updating sdk-installer-config-4.0 as described above is warranted.

Another occasional failure scenario is that the "build failed" email shows that the MD5 checksum is the same, but the cacheID (which is the eTag HTTP Header) is different.  I don't know why that sometimes is the case, but if you see more and more "build failed" messages like that, the remedy is to copy the cacheID from the "new version" in the email to the cacheID2 in the sdk-installer-config-4.0.xml file and update the file in SVN and on the web-site as described above.

In some future, MD5Checker and/or the build.xml could be improved to auto-update the sdk-installer-config-4.0.xml automatically, without human intervention, but that would imply leaving SVN credentials on the CI Server and I am not willing to put my credentials on that machine.  Also, I haven't found a way to "hit the publish button" in ASF CMS through Ant.  I think it is possible if someone wants to try.