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.

Very occasionally, you will update SVN with new MD5s and MD5Checker will still fail!  When this happens, manually check http://flex.apache.org/installer/sdk-installer-config-4.0.xml to see if your changes actually got published.  Sometimes you will miss a step in our web-site publishing process, but sometimes, the ASF CMS just doesn't seem to see the change.  If that happens, I would try manually changing something in the file that doesn't matter, like a cacheID2 for the new entry, or adding an XML comment somewhere and publish again until you see the updates.  If you are having trouble after a few attempts, contact Apache Infra. 

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.

Adding New Entries

To add a new entry, copy an existing entry and update the tag name from VersionAA to VersionAB or whatever is next in the sequence.  Update occurrences of the old version number to the new version number so that the right URL is represented.  No need to worry about the cacheIDs or MD5 entry.  Then save it, commit it to SVN, and publish it.  Then go run MD5Checker locally and follow the update steps above.  You could try to get the cachdID and MD5 entries right by computing the MD5 with some utility and sniffing the eTag header with some packet sniffer, but IMO, it isn't worth it and you might as well check that MD5Checker can read your changes to the sdk-installer-config-4.0.xml file.