| Summary: | Patchwork: display notification in series view when a build is started using the series | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] Patchwork/Patchtest | Reporter: | Paul Eggleton <bluelightning> | ||||
| Component: | Patchwork | Assignee: | Unassigned <unassigned> | ||||
| Status: | IN PROGRESS DESIGN --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | Medium | CC: | belen.barros.pena, benjamin.esquivel, elizabeth.flanagan, jose.perez.carranza, leonardo.sandoval.gonzalez, randy.macleod, richard.purdie, tgamblin, tim.orling | ||||
| Version: | unspecified | ||||||
| Target Milestone: | Future | ||||||
| Hardware: | All | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | Don't know | |||||
| Bug Depends on: | 8648, 8649, 9130, 10506, 10507 | ||||||
| Bug Blocks: | 8715, 8716, 8717 | ||||||
| Attachments: |
|
||||||
|
Description
Paul Eggleton
2015-11-23 21:15:29 UTC
make changes to reflect this bug will go into patchwork instead of the autobuilder. Also, check for its moving out of 2.1 with CCB. Updating target milestone to match that of Dependency CCB is aware of this movement. Moving to 2.3 M1 due to the remaining dependency. I'm using a previous UI design by Belen Barros to implement a functional basic version in a staging instance that is already integrated with Patchtest. Once that is ready it will be presented to team for further discussion on workflow and possible improvements. Initial analysis of the workflow for patch testing report through Patchwork has shown that there should be two paths: one for Patchtest results (mostly useful for patch submitter) and other for build results (mostly useful for maintainers), each one of them in a different view. Next step is to implement a patchtest-results view available from Series view, and improve the build-results view available from Bundle view. Splitting this bug in two sub-tasks tracked in 10506 and 10507. Moving to M2 following 10507 milestone. Moving to M3 following 10506 dependency. Development paused will be resumed upon dependencies completion. Moving this bug to M2 based on roadmap for the dependencies and related bugs. I'm renaming this umbrella bug to reflect the current status for this request. Following are the details on how the initial requirements are/will be handled: (In reply to comment #0) > Create a front-end page for the autobuilder to present the branch containing > the list of patches assembled via the script described in bug 8649, with > links back to patchwork for each patch in the branch. It should be able to > handle multiple repositories but for the moment we'll only concern ourselves > with poky (i.e. bitbake + openembedded-core). The mentioned script from bug 8649 is now know as Patchtest, which posts results in Patchwork Series view. It was generally agreed that the Autobuilder code should not be modified, so any modification will take place in Patchwork only. Patch Series will be obtained from Patchwork and then applied to a test branch to be used in an Autobuilder test build. To track down the series from the Autobuilder back to Patchwork, the "Reason" field at the Build results page will include the series Id number (this is performed through the use of the "test-series" script described below). > > Besides the branch overview, the page should have the following features: > * Plain text comments field to associate notes with the build; this should > be auto-saved. All comments can be sent as replies to the patch email thread, and they are displayed in Patchwork's Patch view. > * Ability to refresh the branch to pick up any changes pushed there by the > maintainer. (Another implication here is that we need to take care that we > don't lose the links to patchwork even if the commits on the branch are > adjusted by the maintainer). The test branches are uniquely-identified when created with the "test-series" script to apply a Patch Series, so when a change is implemented this will result in a new test branch pushed that will be linked to a unique Autobuilder results page. > * Ability to start the build on the branch on the autobuilder + send status > back to patchwork The test builds will be started through the use of the script "test-series", which includes features to download a patch series from Patchwork, create a new test branch to apply the series, push the test branch to a remote repository, start a build at the Autobuilder and post a link in Patchwork to the build results page. These sub-tasks can be performed individually or as an automated sequence. > * Give visibility to any comments picked up by patchwork on the patch after > submission (or new versions), in case a reviewer has pointed out an issue > that should block further integration of the patch. All comments sent as part of an email thread are available at Patchwork's Patch view. > * Authentication should be required to do any editing or actions. > This is required both in Patchwork and in the Autobuilder > For simplicity I think we'd make this a separate frontend page rather than > needing to be built into the autobuilder buildbot code. A first draft of the "test-series" script was reviewed and the second version is being developed to allow performing either individually each one of its steps, or as an automated, continuous process. Created attachment 3869 [details]
test-series script - v1
Script to automate the test build process can be seen at https://lists.yoctoproject.org/pipermail/yocto/2017-August/037404.html Version 2 of script can be seen at https://lists.yoctoproject.org/pipermail/yocto/2017-August/037465.html Review for the script is still in process, and will be resumed after the bug-fixing milestone M4 is done. I'm moving this request accordingly. I'm updating this request's title to reflect the expected outcome from the script in the Series view and the milestone to adhere to current work planning (view previous comment). Next steps for this request are to further reviewing the script v2 (view comment 14) with OE-core code maintainers and evaluate possible testing options. We basically decided not to implement this block of functionality but could revisit in future - moving to medium/future/unassigned accordingly. |