Nightly Builds and Other Infrastructure
michelled33 at gmail.com
Wed Jan 29 21:02:37 UTC 2014
Last week, the server containing our nightly builds got hacked due to an old version of Continuum (the software we were using for creating our nightly builds). That server contained many things on it that the Fluid community has used or currently uses. This is the perfect time to consider each of these pieces of infrastructure and make forward looking decisions for it.
1. We have been wanting to move to using Jenkins for the nightly builds for a long time now, but haven't been able to fit in the cycles to do the actual move. Instead of upgrading Continuum, let's make that move now. Justin, Avtar and I will do the work for this over the next couple of weeks. We have just deployed a new and improved page on the build site: http://build.fluidproject.org/ with links to static demos. Once the move to Jenkins happens, the links from that page will once again be built regularly. Instead of having them happen 'nightly' we plan to use github service hooks to have the build happen on every push to the project repository.
2. We have recently discovered a bug in our current Infusion build which causes our minified builds not to work in IE8. http://issues.fluidproject.org/browse/FLUID-5260 This is another piece of infrastructure that we have been planning to replace. Now is a good time to replace our current Ant builds with the Grunt builds that we have been working on.
3. We have been directing users to the Infusion Builder to create special builds of Infusion, however, the builder often becomes out of date and has breakages that we tend not to notice immediately. With the move to Grunt, creating a special package of Infusion should be easier. Let's consider not putting the builder back up, and instead provide several commonly used packages for download and instructions on creating unique packages using Grunt.
4. We have been hosting an instance of TestSwarm for a long time now and yet it has not become part of the community practise to actually use it. Let's not put it back online until we see a clear need for it in our community.
5. We have been maintaining our own fork of JSLint for a long time now. It's becoming clear that a move to JSHint would be a better fit for our community and would mean less infrastructure for us to host. There is a JSHint plugin for Grunt, which will actually improve our ability to run our tests regularly. We will need to determine which setting to use in JSHint and likely do a pass through of all our files.
Senior Inclusive Developer
Inclusive Design Research Centre, OCAD University
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work