Skip to content

Continuous integration

VictorLowther edited this page Nov 14, 2012 · 4 revisions

This document aims to cover current and future CI (Continuous Integration) infrastructure for automatically testing Crowbar. The details of specific automated test code within the Crowbar repositories falls outside the scope of this document and is covered in Automated testing.

Existing CI infrastructure

  • Dell Build Server runs through smoke test on every ISO
    • Jenkins
    • deploys ISO into a virtual system of multiple nodes (5 node KVM environment)
    • OpenStack -> crowbar, nova controller, nova compute -> runs tempest to make sure Nova is working
    • Cloudera -> deploy's ClouderaManager
    • test of NTP, DNS, etc.
    • each barclamp has smoke tests that are run during the installation (which is part of smoke testing)
  • SUSE Build Server
    • Jenkins builds a new cloud from scratch
    • Install the new builld onto a new VM and automatically config & install Crowbar using CLI
    • Using CLI, nodes are provisioned and proposals added
    • Perform basic operations like uploading, launching, etc

Next steps:

  • Dev tool changes:
    • Add a unique ID for each pull request bundle [DONE]
    • Teach the dev tool how to find open pull requests, and group them by pull request bundle ID.
    • Teach dev tool how to locally merge pull request branches that are part of a bundle.
    • Teach dev how to figure out what release/build/OS combinations need to be tested based on the contents of a pull request bundle.
    • Teach dev tool how to track testing state in a seperate Git repository.
  • Dell build system changes:
    • Remove all git-related knowledge from build_crowbar.sh, and push it into dev.
    • Disentangle the VM runner parts of the smoketest framework from the rest of the build system.
    • Make dev and the smoketest framework logically independent in preperation for splitting them out.
    • Decide on better tracking method for release-specific metadata and build system components.
  • Jenkins changes:
    • Add job to watch for pull request bundles, and kick off CI passes on those bundles.
    • Teach Jenkins how to use dev to track and update state for pull request bundles.
    • Teach Jenkins how to parallelize builds out based on the what dev says needs to be built and tested for each pull request bundle.
    • Teach Jenkins and dev how to implement the Gating State Machine.
  • Open Questions:
    • How to handle singleton pull requests?
    • How to handle validating that changes conform to the CLA?
Clone this wiki locally