Nightly Builds and Other Infrastructure

[Gill, Avtar]

> Can someone outline the features and benefits that Jenkins will provide us in comparison to a simple script that listens for Github hooks? I’m sure there are good ones, I’d just like to hear them enumerated.

Jenkins would allow one to view all builds and statuses (whether a build was successful or not) in one location. In addition to serving build artifacts it would also provide a history of each build showing how each commit affected a particular project. Having scripts triggered by commits could result in an unwieldy process as time goes on as opposed to a more scalable approach of letting Jenkins oversee the testing process and then pushing the resulting artifacts to VMs that would be dedicated to just serving them. If TestSwarm (or an alternative like http://karma-runner.github.io) needs to be revived in the future we will benefit by having Jenkins in the picture along with its various plugins.

Avtar

On Jan 29, 2014, at 4:35 PM, Colin Clark <colinbdclark at gmail.com> wrote:

> Hi Michelle,
> 
> On Jan 29, 2014, at 4:02 PM, Michelle D'Souza <michelled33 at gmail.com> wrote:
> 
>> 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.  
> 
> Can someone outline the features and benefits that Jenkins will provide us in comparison to a simple script that listens for Github hooks? I’m sure there are good ones, I’d just like to hear them enumerated.
> 
>> 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. 
> 
> +1. If we are in a bind, I suggest we simply replace the “minify” target in buildutils.xml to invoke Uglify instead of YUI Compressor. But we’re going to need to move to Grunt before we ship 1.5, I think.
> 
>> 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.
> 
> +1. Graphical UIs are really nice, but developers are very comfortable with Grunt these days. And given that I hope we will consider splitting out the components from the framework post-1.5, we’d have to rethink what a “distributed builder” would look like anyway. So ditching it sounds like a great idea to me.
> 
>> 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. 
> 
> I think there is a clear need for TestSwarm or something similar in our community already. The problem is that we need to have sufficient critical mass of cross-browser test agents, which really requires us to have VMs dedicated to the task of testing. And it needs to be tightly integrated into our workflow, sending emails or IRC bot messages when failures occur.
> 
> Given these requirements, I think we’re best to live without Test Swarm long enough to get our cloud infrastructure running and then revisit the issue. We do need it, though. We’ve had subtle breakages in IE that went unnoticed because developers weren’t testing manually on it. Test Swarm would have caught these kinds of issues, but we’re just not in a position to be able to maintain it right now.
> 
>> 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. 
> 
> +1. I have switched to JSHint for Flocking and it’s been a pleasure to use with Grunt. And it doesn’t insult users with insane Crockford-isms like the “stupidity” checkbox. Let’s definitely update our comment blocks (or use a .jshintrc file in the project) and switch to JSHint.
> 
> Colin
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work