[Interest] New CI for Qt (and OpenSource Qt/QtC 3rd parties)

Sarajärvi Tony tony.sarajarvi at theqtcompany.com
Fri Dec 11 09:16:01 CET 2015


	> I added your reply to my personal Wiki.  Is there a public Qt CI Wiki?  This overview might be nice to add to it for others to find.
	
Yes there is, but they have been neglected for some time. I should perhaps go through them and update them with some useful information.


	> I cannot find any reference to "Coin CI".  Is this an open source or commercial tool?  A Qt internal tool?

Internal tool created from nothing. Sources aren't public as of yet anyway

	> So you have multiple OVF VM templates on your SAN that you deploy dynamically?  Like one OVF for VS2012, one for VS2015, etc?

Actually they are just VmWare templates, but yes on the SAN. We create linked clones of the 'master' templates for cloning a VM. That way any new VM is created in seconds instead of cloning the whole VM.

We actually have combined all SDK's into the same template VM, but by changing PATH, LIB, INCLUDE etc on the fly, we choose which versions we want to use. So our Windows 7 template includes 3 or 4 different Visual Studios.

	> I should research Puppet for clean OS build machine creation for OS X, Windows, and Linux.  I really liked RHEL kickstart file for the purpose.  Perhaps Puppet can be used to provide a similar solution for other platforms.
	
Yes, Puppet can be used for it. However we tend to dislike the syntax and complexity of those scripts. I'd compare solutions before running into Puppet ;)	
	
 

	> In my current work I Windows and OS X build VMs.  I would not know where to start to create clean slate OS installer scripts for these platforms.  Maybe Puppet.

Chef is also one we investigated here, just to mention an alternative.
While working with virtual machines however, you might want to weight the benefits of scripting things. With virtual machines you can create quick backups and also use snapshots to get back to previous states. So in theory you only need to install stuff once. Scripting that takes longer than it actually takes for you to install it manually, so depending on the use case you have, you might be better off by just having the install commands listed in a text document :P Also keep in mind the reverse engineering that has to be done by the next person when you do scripts. A plain text document is more readable by anyone.

	> Thank you for your time!
Anytime :)


	> -Ed
-Tony



More information about the Interest mailing list