On 12/12/2011, at 4:59 PM, Rohan McGovern wrote: > Laszlo Papp said: >> >> 1) Build and software testing service >> Is there a build and software testing service provided for projects in >> the Qt Playground repositories ? I have not seen any mentionings about >> that so far. and it is an important question in my case, for instance. >> I have been using CDash [1] for projects under the KDE umbrella. It is >> possible as long as I use cmake as a build system in my project. I >> think such a build and software testing service along with the >> publishing of the build results would increase the QA of those >> playground projects. I know there are such QA services for "final" >> modules. I was just curious if those tools, providing the relevant >> services, are available to Qt Playground projects or not. If not, are >> there some other options ? It would be really nice if playground >> projects could get such an attention. I am not willing to propose it >> for all the projects there because I do not know the capacity, but at >> least for projects and maintainers there who are interested in this >> matter. >> > > Security is a potential issue for providing the same test resources > used for the main Qt modules to be also used against playground > modules. These test machines are Internet-connected[1], and arbitrary code > can be set up to run on them; lowering the barrier for getting this > arbitrary code onto the machines of course increases the security risk. > >> http://my.cdash.org/ > > It would be interesting to know for example how Kitware handled this > issue for the above, or if it was explicitly decided to accept the risk > (which may well be a valid approach, given that the process includes a > trusted maintainer signing off on the new playground project). >
As someone who maintains a couple of platforms for the CMake dashboard (ie LSB linux builds), I'll throw in my $0.02. The CDash model works in reverse to what I suspect you might be thinking. The server that hosts the dashboard merely accepts an XML summary of the results of a build. The build itself could be done on any machine that can connect to the dashboard server, including sitting behind a private company firewall, etc. In our case, we have a virtual machine start up, run the build and then shut down again. For nightlies, you can even have the VM wipe all changes made and start up with an identical clean system every time (we do this), but for CI you can just have the virtual disk holding the build tree preserved and let the virtual system disk start up clean each time, etc. But I digress...... My main point is that the maintainer of the machine carrying out the build is the one taking the risk, not the machine hosting the CDash site. No arbitrary code is executed on the CDash server, only the build machine. In the case of the Qt playground, such a model would allow maintainers of a playground component to host their own builds and submit results to a central dashboard (I mean that term generically, I'm not implying that I think this should necessarily be CDash). If a playground project moves to an accepted add-on, then perhaps the builds could be taken over by some central pool of build servers since at that point, the source code has essentially been accepted as trustworthy. If there's a desire to have Qt's pool of servers also support builds for playground projects, then one option would be to use the approach of virtual machines which reset their disks back to a known state before each build. I really like the model of enabling the community to submit build results to a central dashboard. It allows those with an interest in a particular platform/compiler combination to put in the initial setup work and have their combination included in the automated build/test infrastructure. The Kitware guys make it easy with simple instructions to get a build submission up and running this was a key factor for me to add builds for the platforms/compiler that matter to our group. Heck, it even motivated me to set up similar things for the rest of our code base, so I guess we're proof that such a system can encourage better habits. I've missed not having a similar thing for Qt. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
