The development process of the Open Build Service (OBS) code base as well as it’s accompanying tools is largely test-driven. Major parts of the OBS source code are covered by a comprehensive test-suite. Traditionally, after each new code submission, these tests have been run by a custom shell-script on a local machine that wasn’t publicly available for several reasons. Even though this setup served us well for a long time, but we needed more. We want to provide a more transparent solution that allows the community to participate and maybe take over some responsibilities. Thus, your hard-working OBS-team hereby kindly introduces ci.opensuse.org, our new public interface for continuous integration (CI) testing!
Archive for the ‘Infrastructure’ Category
The last few days those of you linked to the planet by http://planetsuse.org/ are experiencing connection problems. This is not because openSUSE Planet is down but as Pascal Bleser announced a few days ago into the openSUSE Project ML because this domain name is not under the Project’s control but by and individual who left the openSUSE Project some years ago.
One of the most important activities during software development is testing. In FOSS community, software often gets tested by the developers themselves, other developers and volunteers. During the openSUSE 12.1 development process it has been important to keep Factory working properly. Testing this is however a rather boring, repetitive task: the tester has to boot up a Factory ISO as often as possible and check if the basic applications start up and work. We don’t like boring tasks so the openSUSE Project has been using the automated testing framework openQA to test this release daily!
This article explains how openQA works and how you can help keep Factory working! We’ll also give some links to more information about testing to help new testers learn the trade but also give experienced testers some new tips and insights!
Testing is generally done on the latest development release, with additional testing sometimes done using updates from Factory to verify bug fixes. Everything in Factory is passed through our automated test framework openQA. You can read more about openQA an the announcement openSUSE News. openQA is a great test suite and is capable of producing videos of the whole process and also screenshots. This greatly reduces the overhead for the testers. An overview of the test results can be found here.
openQA can be used both for bug reporting and bug triaging. To find and report bugs using openQA just visit the openQA test result page, browse through the web interface and look for failed tests. Click on the corresponding tests, to view the results. If your copy of openSUSE is different from the version that has been tested at openqa but you want to/need to do additional testing, fire up your vm and install the version openQA used (or a newer one). You can check for bugs in the tests that have not been autochecked and also look for hardware related (note that in this case you will need to install it on your system instead of a vm) and other possible bugs that openQA might have missed. If you find a bug, report the bug to our testing team or file the bug yourself. Be sure to make good use of the openSUSE Testing documentation at the Testing portal, the Bug report how-to and read the Bug Reporting F.A.Q!
Bernhard, the author of openQA has come out with a nice web interface for bug triagers to make them easier to browse through bugs. The web interface provides with a list of some random bugs. If you are interested ino a scpecific component, then you can use the search bar and look for them. Once you have a random list of bugs that may interest you, you mark a bug as taken. This will reserve the bug. Now fix the bug and update the bugzilla accordingly to get more info or mark it as fixed. While the real triaging is still left for the developers to do, the web interface makes it easierfor them to find bugs..
Adding tests to openQA
An important part of openQA are of course the tests themselves. The more tests are written the more openQA can cover. Tweaking preexisting tests or creating new tests is not very difficult. You can get the sources of openQa from gitorious. You will need it to have the examples and tools needed to build new test cases. Once you have the source, you can find the test modules spread across os-autoinst directory. Every test module has two parts, one which contains the general flow of sendkey events to test an application or feature, the second one being a set of md5 hash sums to determine the validity of test results. os-autoinst/bmqemu.pm can act as a reference for the functions that can be used in our test modules. The commands can be used to write the desired test module. To verify if the test results are valid or not, a set of md5 hash sums of screenshots of the desired results is checked. To calculate these hashsums you can use tools/inststagedetect2.pl. The following article provides an indepth howto on writing a test module in openQA.
If you need help/support in testing, if you have topics to discuss or if you are just interested in this area, join the firstname.lastname@example.org mailing list (see openSUSE:Mailing lists page how to subscribe). Have a look at the Testing portal or directly contact our core testing team
The openSUSE Project announces the 1.0 release of the unique cross-distribution-capable, fully automated testing framework openQA. openQA is the only comprehensive testing tool which can run tests on every level of the OS, from core functionality like the bootloader and booting the kernel up to testing applications like Firefox and LibreOffice. It shows the results in a convenient web interface and allows testers to see screenshots and even videos of the issues found. openQA is used to run nightly tests of the ‘Factory’ development repository for the upcoming openSUSE 12.1 release. openQA is available under the GPL version 2 or later.
The OBS-Team is going to replace some backend servers on next Tuesday.
Therefore, a downtime is scheduled from 08:00 to 11:00 CEST, altough we believe it won’t take that long (but you never know) :-)
Afterwards, the OBS should be prepared for all the awesome packager workshops happening during the openSUSE Conference.
Aloha openSUSE Users!
Now is an excellent time to help openSUSE! If you have openSUSE running on your system, all you have to do is add your hardware to the openSUSE Hardware compatibility List. Add your pheriphials like printers, scanners and webcams. Or add internal stuff like graphics and sound cards, mother boards, wifi cards and every thing else from your netbooks, notebooks, desktops and workstations!
We are currently facing a hardware problem with the openSUSE Build Service.
Affected services are:
We are trying to resolve this as fast as possible. Apologies for inconveniences this may cause.
Please contact email@example.com with any queries.
Your openSUSE Admins
Update 18:53 UTC: Everything is up and running again. Note the build service scheduler needs to read all files now and create some data structures. It will take a few hours until the build service is building again packages.
Yesterday was World IPv6 Day and openSUSE participated in it. We hope the experiment was as successful for the other participants as it was for us!
Here is a short status update from the openSUSE infrastructure. openSUSE has currently two major server locations and we tested IPv6 at both separately. Note that there are more openSUSE infrastructure locations, including the server which runs the popular planet.opensuse.org (which supports IPv6 as well now)! (more…)
The openSUSE kernel developers have recently announced that the kernel git trees have moved to kernel.opensuse.org/git, providing better reliability than gitorious. Gitorious had trouble with cloning the nearly 1GB repository sometimes, but the developers will keep syncing to gitorious so nothing should break. Moreover, kernel.opensuse.org offers an easy interface to install openSUSE kernels on a variety of openSUSE releases.