Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
- one pushes into a special "staging" branch (e.g. st-XXX)
- buildbot builds/tests it
- if all is ok, buildbot rebases (or merges, depending on the content) it on top of the main branch, builds/tests again, and pushes into main
- optionally, updates pushed MDEVs from "Building" to "Closed"
- sends the result (success or failure, and what exactly failed) to the developer
optimizations:
- if something is built/tested in the st-* branch, there is no need to do it again in the main branch.
- if there are two pushes into two separate st-* branches, may be it would make sense to rebase/merge them first and build/test them in one buildbot run, not in three (first, second, merge).
Attachments
Issue Links
- blocks
-
MDBF-732
protect main branches in github (gatekeeping)
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
* one pushes into a special "autopush" branch (e.g. ap-XXX)
* buildbot builds/tests it * if all is ok, buildbot rebases (or merges, depending on the content) it on top of the main branch, builds/tests again, and pushes into main * optionally, updates pushed MDEVs from "Building" to "Closed" * sends the result (success or failure, and what exactly failed) to the developer optimizations: * if something is built/tested in the ap-* branch, there is no need to do it again in the main branch. * if there are two pushes into two separate ap-* branches, may be it would make sense to rebase/merge them first and build/test them in one buildbot run, not in three (first, second, merge). |
| Description |
* one pushes into a special "autopush" branch (e.g. ap-XXX)
* buildbot builds/tests it * if all is ok, buildbot rebases (or merges, depending on the content) it on top of the main branch, builds/tests again, and pushes into main * optionally, updates pushed MDEVs from "Building" to "Closed" * sends the result (success or failure, and what exactly failed) to the developer optimizations: * if something is built/tested in the ap-* branch, there is no need to do it again in the main branch. * if there are two pushes into two separate ap-* branches, may be it would make sense to rebase/merge them first and build/test them in one buildbot run, not in three (first, second, merge). |
* one pushes into a special "autopush" branch (e.g. st-XXX)
* buildbot builds/tests it * if all is ok, buildbot rebases (or merges, depending on the content) it on top of the main branch, builds/tests again, and pushes into main * optionally, updates pushed MDEVs from "Building" to "Closed" * sends the result (success or failure, and what exactly failed) to the developer optimizations: * if something is built/tested in the st-* branch, there is no need to do it again in the main branch. * if there are two pushes into two separate ap-* branches, may be it would make sense to rebase/merge them first and build/test them in one buildbot run, not in three (first, second, merge). |
| Description |
* one pushes into a special "autopush" branch (e.g. st-XXX)
* buildbot builds/tests it * if all is ok, buildbot rebases (or merges, depending on the content) it on top of the main branch, builds/tests again, and pushes into main * optionally, updates pushed MDEVs from "Building" to "Closed" * sends the result (success or failure, and what exactly failed) to the developer optimizations: * if something is built/tested in the st-* branch, there is no need to do it again in the main branch. * if there are two pushes into two separate ap-* branches, may be it would make sense to rebase/merge them first and build/test them in one buildbot run, not in three (first, second, merge). |
* one pushes into a special "staging" branch (e.g. st-XXX)
* buildbot builds/tests it * if all is ok, buildbot rebases (or merges, depending on the content) it on top of the main branch, builds/tests again, and pushes into main * optionally, updates pushed MDEVs from "Building" to "Closed" * sends the result (success or failure, and what exactly failed) to the developer optimizations: * if something is built/tested in the st-* branch, there is no need to do it again in the main branch. * if there are two pushes into two separate st-* branches, may be it would make sense to rebase/merge them first and build/test them in one buildbot run, not in three (first, second, merge). |
| Summary | autopush in buildbot | staging and fire-and-forget |
| Assignee | Rasmus Johansson [ ratzpo ] |
| Link |
This issue blocks |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Assignee | Rasmus Johansson [ ratzpo ] | Vicențiu Ciorbaru [ cvicentiu ] |
| Assignee | Vicențiu Ciorbaru [ cvicentiu ] | Sergei Golubchik [ serg ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Assignee | Sergei Golubchik [ serg ] | Vicențiu Ciorbaru [ cvicentiu ] |
| Workflow | MariaDB v3 [ 80336 ] | MariaDB v4 [ 143505 ] |
| Status | Stalled [ 10000 ] | Open [ 1 ] |
| Key | MDEV-12511 | MDBF-730 |
| Project | MariaDB Server [ 10000 ] | MariaDB Foundation Development [ 11901 ] |
| Parent |
|
|
| Issue Type | Technical task [ 7 ] | Task [ 3 ] |
| Component/s | Buildbot [ 18503 ] | |
| Component/s | Github [ 20211 ] |
| Workflow | MariaDB v4 [ 143505 ] | MariaDB Foundation v1 [ 188099 ] |
| Rank | Ranked lower |
| Labels | foundation |
Hi ratzpo,
This autopush task looked exactly like the staging and fire-and-forget functionality that you are working on now, so I adjusted a little bit the description and title to conform to our current terminology and assigned to you. Can you please go ahead and update this with the actual functionality you are testing right now and use it going further?