Views
Release Engineering/Process/Automation
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
- 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)