Revision as of 10:32, 10 October 2011

Automating DE processes

The DE workflow is (roughly) :

1. Developer branches package from P:DE:Trunk
2. Developer submits package to P:DE:Trunk:Testing
3. Boss runs checks on package
4. Boss creates branch of P:DE:Trunk
5. Boss submits package(s) to new branch

Later:

1. Boss rejects package

or

1. Boss notifies maintainers that checks passed

Then:

1. Package is accepted to P:DE:Trunk by a maintainer
2. bz is updated

The actual processes can be seen in the autodoc boss area until the OBS plugin is available.

BOSS Checks

An SR for one or more packages into the Testing project is seen by BOSS.

BOSS runs the following checks (and stops as soon as one fails)

• check_submitter_is_maintainer
• check_package_built_at_source
• check_package_is_complete
• check_spec

To be done:

• changelog in proper format (present, syntactically correct)
• changelog has entry for this commit
• last changelog version matches spec file version
• tarball not changed within same package version
• executing spectacle doesn't change anything if .yaml present
• yaml must be present if spec is based on .yaml
• content of source tar ball should not change without its changing.
• check that old tarball has been removed if new one is introduced
• SR not empty (define empty?)
  • No changes at all. At times people are trying rebuild packages by submitting empty change. (Sage)

Then it tries to build the package in a 'link' project.

This project should be dynamically created and retained in the event of failure for diagnostics. BOSS should then clean up the dynamic project (when told, or after a time).

An image is created using the newly built package(s) and any packages rebuilt in the link project. (Clarify - only those mentioned in the .ks or *all* rebuilt packages?)

Eventually the image will be processed by OTS.

Once all checks have been run the request will be either accepted or marked for acceptance.

Process Testing

The Project:DE:BOSS:Trunk and Project:DE:BOSS:Trunk:Testing areas are used to test the processes.

The processes to be tested are deployed to /srv/BOSS/processes/Project/DE/BOSS/Trunk/

DE_Trunk_SRs

To deploy:

• set irc_channel and final_project
• Copy to Project:DE:Trunk
• symlink: SRCSRV_REQUEST_CREATE and SRCSRV_REQUEST_STATECHANGE in Trunk and Trunk:Testing

  cd Trunk
  ln -s DE_Trunk_SRs SRCSRV_REQUEST_CREATE SRCSRV_REQUEST_STATECHANGE
  cd Testing
  ln -s ../DE_Trunk_SRs SRCSRV_REQUEST_CREATE SRCSRV_REQUEST_STATECHANGE

Wish List

List of wishes for the BOSS. Please write your nick in parentheses to the end so people know who to contact if they have more questions.

1. e-mail notice of SR's especially when SR is rejected
2. Check if package upstream has changed and do a report of the packages that needs to be rebased on top of the new upstream. Currently this check is done manually with https://gitorious.org/meego-developer-edition-for-n900/upstreamchecker/ script by N900 RE. (Sage)
3. In case package fails to connection failure start rebuild automatically after time X. (Sage)
4. Add architecture and repository to build error message. (Sage)
   • 14:06.33 < boss> Build failure in Project:DE:Trunk:Testing: meegotouch-theme More details soon
5. Update patterns based on package-groups package. (Sage)
   • We should have package-group package in the Project:DE:Trunk[:Testing] project that contains the CE package groups. This information should be when ever repository is published pushed to the repository with osc meta pattern or similar command.
6. When submit supersedes another one the handling of the old submit request should be stopped. (Sage)
7. SR email subject should include Rejected/Accepted %fromproject to %toproject : %packagelist.
8. Check that there isn't any other files generated to the filesystem than the files in  %files section after installing the package. This might not be a reason for rejection but in many cases this is hack in packaging that must be removed. So if this happens there should be NOTE in the package review that is given to RE (sage)
9. When running the specify it at times shows warnings when executing it. It would be nice if these warnings (the output) would be shown in the report, I don't mean failing the test but show in the report so user would see what could be also fixed. (Sage)

Bug Lifecycle

The DE bug lifecycle is (roughly):

• 'open' -> FIXED -> RELEASED -> VERIFIED

1. Developer starts working on the bug/feature and sets to ASSIGNED
2. Developer submits package to P:DE:Trunk:Testing and documents changelog and/or commit properly (fixes bmc #1234;) - if changelog doesn't have a valid bug/feature reference the request MUST fail but we do not document the failure in the bug report
3. Bugzilla records the commit message with link to the repo and timestamp
4. Package is accepted to P:DE:Trunk (manual for now....)
5. Bugzilla records acceptance with comment and bug status is automatically changed to FIXED if bug is still in OPEN status (New, assigned, needinfo, reopened, waiting)
6. If bug is already in FIXED resolution, only acceptance comment is written in the bug report
7. If bug is not in OPEN status (New, assigned, needinfo, reopened, waiting) or resolved FIXED (eg. duplicate, wontfix, etc... or verified or closed) the request MUST fail but we do not document the failure in the bug report

Later:

1. Release is triggered
2. Bug status is automatically changed to RELEASED, a comment with a link to the image is created and the Target Build value is set to match appropriate release

Later still:

1. QA review the release and for each bug marked RELEASED, either change to VERIFIED or re-open

Note that eventually, both FIXED and RELEASED statuses would require specific credentials to be modified.

Image Building

CE has a private installation of IMG on host img in the internal meego.com network. Speak to David Greaves / lbt for access details. Login is via meego.com credentials.