From Fedora Project Wiki
Line 34: Line 34:
= Work in progress =
= Work in progress =
* Integration with Bodhi
* Integration with Bodhi
* ARM Release criteria

Revision as of 13:53, 18 April 2012

Introduction

AutoQA

AutoQA is the automated test system used in Fedora. Watchers (scheduled through cron ) look for Events ( eg - new package built in Koji, new repo has finished, creation of new installable images, updates in bodhi ). Once an event occurs it triggers automated tests.

Current Events monitored

  • git-post-receive - tests run after action performed in git.
  • post-bodhi-update - update in Bodhi requests to be moved in 'testing' or 'stable'.
  • post-bodhi-update-batch
  • post-koji-build - new package built in Koji.
  • post-koji-build-batch
  • post-repo-update - change in repository package contents or metadata.
  • post-tree-compose - new tree compose ( installation/boot images, package repository and metadata )

Current Tests

  • conflicts - checks for package conflicts. Runs potential_conflict from yum-utils. ( triggered by - post-repo-update )
  • depcheck - checks to see if package would cause broken dependencies if pushed to live repositories. ( triggered by - post-bodhi-update event )
  • rats_install - installation of guest machine(virt-install) using latest compose. ( triggered by - post-tree-compose)
  • rats_sanity - Repository sanity check - tests check repodata, comps.xml validity, core package dependency closure and existence. ( triggered by - post-repo-update )
  • repoclosure - ensures packages in a repository have all dependencies satisfied. ( triggered by - post-repo-update )
  • rpmguard - compares difference between new and previous package versions, logging important changes only. ( triggered by - post-koji-build)
  • rpmlint - checks for common package issues ( triggered by - post-koji-build )
  • upgradepath - checks for package version problems in repositories. ( triggered by - post-bodhi-update-batch )

ARM specific tests

Some tests will need to be written specifically for ARM including:

  • Image validation
  • Individual package tests

Hardware Access & Repair

Currently not everyone working within Fedora has access to an ARM device so it necessary to provide access to developers to test their software. Once their testing is completed, the device needs to be restored to a pristine state. At this time Anaconda is not fully functional, so some possible solutions include:

  • SD card switch - allows access to be transferred remotely from card reader to ARM device, allowing for remote machine repair.
  • QEMU

Work in progress

  • Integration with Bodhi
  • ARM Release criteria