Release Engineering/Process/Automation

Revision as of 18:46, 8 November 2010

Process Automation

Promotion Workflow

• Maintainer submits request from Devel:Project
  • BOSS reviews the requests
    • if PASS 5 checks put comment
    • if FAIL 5 checks, reject

• • Trunk:testing maintainer accepts a few requests
  • BOSS picks up REPO_PUBLISH
  • BOSS waits T-X minutes if no new REPO_PUBLISH events, notifies maintainers
  • maintainers stop new activity
  • BOSS waits X minutes more if no new REPO_PUBLISH events, trigger pre_promote process

pre_promote:

• • create the correct repo structure
  • Trigger IMG builds images
  • IMG returns result (Success , Location)
    • BOSS receives IMG Success event
      • BOSS initializes a comliancy test
      • BOSS notifies release managers of the compliancy report
    • BOSS notifies maintainers and QA of new images
  • QA teams test and send report
  • Trunk:Testing maintainer makes decision based on QA report
  • IF decision is PASS
    • maintainer submit request to TRUNK
    • BOSS accepts it automatically
  • Other
    • revert broken pkgs
      • restart pre_promote
    • revert ALL
  • end cycle

The checks

• policy check
  • from which prj is sent
  • if pkg exists in Trunk:Testing, the request has to come from a link of the pkg in trunk
  • pkg in request has to have been built successfully in source project
  • pkg in request has to have been built against the correct target (repo path)
  • if pkg has a devel project, pkg should be submitted from the devel project, else it can come from other sources

• changelog checks
  • has bug ID or FEA ID
  • syntax complies with packaging guidelines
  • target build is correct in BUG
  • BUG belongs to correct version
  • BUG status is resolved

• pkg complies with pkging guidelines (rpmlint)