| # Using the Auto-submit Bot | |
| This page details the workflow for Flutter's Auto-submit bot and how to use it to submit your changes into Flutter owned repositories. | |
| ## Auto-submit Labels | |
| ### Label descriptions and Who Applies these Labels | |
| The following is a table of the labels that Auto-submit currently responds to | |
| and who adds them. | |
| | Label | Description | Human | Bot | Why? | | |
| | --- | --- | :---: | :---: | --- | | |
| | `autosubmit` | Merge a pull request when the tree becomes green. | X | | Merge on a validated pull request. | | |
| | `revert` | Label used to initiate a revert request on a closed and merged PR. | X | | Revert a particular change that has been merged. | | |
| | `revert of` | Tracking label for the revert request generated from the closed and merged original pull request. | | X | To track the new pull request that reverts a previous change. | | |
| | `emergency` | Override the tree-status check and land even when the tree is closed. | X | | To submit a potential fix for the current tree-status. | | |
| Note that `emergency` cannot be used on its own and should be used in | |
| conjunction with the `autosubmit` label. | |
| ### Usage Examples | |
| #### Merging a change (tree is open) | |
| This is the happy path. The tree is green and you just need to make | |
| sure validations pass and have the correct number of reviews. | |
| **Labels to use:** [ `autosubmit` ] | |
| **Validations:** | |
| * ci checks | |
| * approvals (2 from flutter hackers) | |
| * mergeability | |
| #### Merging a fix on red tree-status (tree is closed) | |
| This path should only be done in the event you have a change that will | |
| contribute a fix to the status of the tree. | |
| **Labels to use:** [ `autosubmit`, `emergency` ] | |
| **Validations:** | |
| * ci checks | |
| * approvals (2 from flutter hackers) | |
| * mergeability | |
| * ignores the results of the tree status check. | |
| Warning: if you are not merging a fix for the tree you should not use the | |
| `emergency` label. You will need to wait for the tree to open again. | |
| #### Reverting a change from the tree | |
| This path is a way to revert a broken change from the tree that is | |
| within 24 hours old. | |
| The reasoning behind this is that there will be someone with context as to | |
| why the change needed to be reverted. | |
| Note: that it might make sense to add the `warning: land on red to fix tree breakage` | |
| label to a revert request but you do not need to do this. The revert request is | |
| assumed to be done out of urgency. | |
| **Labels to use:** [ `revert` ] | |
| **Validations:** | |
| * "required" ci checks \* | |
| * mergeability | |
| \* There are two types of required 'ci checks'. Ones that are controlled | |
| by/through GitHub and those enforced through our auto-submit configuration | |
| (TODO add link to the config). Currently there is only one required check in | |
| both cases but the later can be extended to support additional checks. | |
| #### Reverting older changes from the tree | |
| This path describes what you should do in order to revert a change that is | |
| older than 24 hours. | |
| In this case you will need to open the revert request in the traditional way. | |
| That is by navigating to your change in the GitHub UI and clicking the | |
| 'Revert' button from the pull request page. | |
| The pull request will then need to be treated as a regular pull request where | |
| you will need to wait for all ci checks to complete and gather 2 reviews from | |
| members of the 'flutter-hackers' team. See | |
| [Merging a change (tree is open)]() above. |