(Refactor stories and add acceptance criteria) |
(add more tasks) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
* Adopting a package | * Adopting a package | ||
* Unretiring a package | |||
* Notification of orphaned packages to the devel mailing list + retirement after 6 weeks | |||
* Notification of packages with broken deps prior to branching + retirement at branching | |||
* Notification of packages that failed to build + retirement | |||
* TBD | * TBD | ||
Line 18: | Line 22: | ||
* the package is not retired | * the package is not retired | ||
* the package is actually orphaned | * the package is actually orphaned | ||
* the person adopting the package is in the packager FAS group | * the person adopting the package is in the packager FAS group | ||
Line 30: | Line 33: | ||
|- | |- | ||
| Acceptance Criteria: | | Acceptance Criteria: | ||
1 - Verify that the provided package is not a retired package, if retired an error message is displayed | |||
2 - Verify that the provided package is owned by the orphan user, if not an error message is displayed | |||
3 - When all conditions are met a success message is displayed | |||
|} | |} | ||
===== '''Automating processing''' ===== | ===== '''Automating processing''' ===== | ||
Line 49: | Line 48: | ||
|- | |- | ||
| Acceptance Criteria: | | Acceptance Criteria: | ||
1 - Creating a new ticket on "https://pagure.io/releng/issues" with the title "Unorphan <package_name>" triggers the | 1 - Creating a new ticket on "https://pagure.io/releng/issues" with the title "Unorphan <package_name>" triggers the unorphaned checks. | ||
2 - If all conditions are met, | 2 - If all conditions are met, checks if the requester is a member of the packager FAS group. | ||
3 - If the requester | 3 - If the requester is a packager make him the package owner in src.fp.o | ||
4 - When successful | 4 - When successful updates the original ticket with a comment and close the ticket. | ||
5 - If the conditions are not met or the requester is not a packager | 5 - If the conditions are not met or the requester is not a packager, comment the original ticket with the failure reasons and close the ticket. | ||
|} | |} |
Latest revision as of 08:54, 7 February 2019
Release Engineering Automation
This is a working document that aims to identify and breakdown the work needed to automate most of Fedora Release engineering.
Release Engineering Tasks that would benefit from automation
- Adopting a package
- Unretiring a package
- Notification of orphaned packages to the devel mailing list + retirement after 6 weeks
- Notification of packages with broken deps prior to branching + retirement at branching
- Notification of packages that failed to build + retirement
- TBD
Adopting a package
Currently when a packager wants to adopt a package that was previously orphan he needs to file a ticket for releng to process the requests (example : https://pagure.io/releng/issues?status=Closed&search_pattern=orphan)
The following need to be true for a package to be successfully adopted.
- the package is not retired
- the package is actually orphaned
- the person adopting the package is in the packager FAS group
When all these conditions are meet the following script can be use to give the package https://pagure.io/releng/blob/master/f/scripts/distgit/give-package.py
Automating checks
As a release engineer I want to automatically check if a package can be unorphaned. |
Acceptance Criteria:
1 - Verify that the provided package is not a retired package, if retired an error message is displayed 2 - Verify that the provided package is owned by the orphan user, if not an error message is displayed 3 - When all conditions are met a success message is displayed |
Automating processing
As a release engineer I want new tickets with "Unorphan <package_name>" title to automatically process the request. |
Acceptance Criteria:
1 - Creating a new ticket on "https://pagure.io/releng/issues" with the title "Unorphan <package_name>" triggers the unorphaned checks. 2 - If all conditions are met, checks if the requester is a member of the packager FAS group. 3 - If the requester is a packager make him the package owner in src.fp.o 4 - When successful updates the original ticket with a comment and close the ticket. 5 - If the conditions are not met or the requester is not a packager, comment the original ticket with the failure reasons and close the ticket. |