... | ... | @@ -15,12 +15,12 @@ done |
|
|
|
|
|
Submitting a patch for incorporation into the tree is done by creating a *merge request*. The merge request serves as a place to conduct code review, collect continuous integration results, and eventually merge your patch.
|
|
|
|
|
|
## Merge Request Workflow
|
|
|
## 1. Merge Request Workflow
|
|
|
|
|
|
|
|
|
<!-- TODO: The label workflow needs to be implemented -->
|
|
|
|
|
|
1. If you're fixing a bug then have a look at [fixing bugs](working-conventions/fixing-bugs) else if you're adding a feature see [adding features](/working-conventions/adding-features).
|
|
|
1. If you are fixing a bug then have a look at [fixing bugs](working-conventions/fixing-bugs) else if you are adding a feature see [adding features](/working-conventions/adding-features).
|
|
|
1. **Open an MR:** see [merge request conventions](/gitlab/merge-requests) and [below](#opening-a-merge-request) for the basics of opening an MR.
|
|
|
<!-- * ~"MR::1-needs triage" label is set automatically. -->
|
|
|
1. **Triage** can be performed by any developer including yourself (see [MR triage protocol](/gitlab/merge-requests#triage-protocol)). This should be done within 1 day.
|
... | ... | @@ -34,7 +34,7 @@ Submitting a patch for incorporation into the tree is done by creating a *merge |
|
|
|
|
|
If you are blocked waiting at any stage then please apply the ~"Blocked on Review" label to draw attention to the MR.
|
|
|
|
|
|
## Opening a merge request
|
|
|
## 2. Opening a merge request
|
|
|
|
|
|
To open a merge request:
|
|
|
|
... | ... | @@ -48,9 +48,9 @@ To open a merge request: |
|
|
8. Write a description of your change. This should be ideally at very least a few sentences to help reviewers understand what you have done. If your change requires any changes to [submodules](https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/git/submodules), please be sure to include links to the upstream merge requests in your description.
|
|
|
9. Click on the green *Submit merge request* button.
|
|
|
|
|
|
## Working with your merge request
|
|
|
## 3. Working with your merge request
|
|
|
|
|
|
Your merge request shows you several panes information:
|
|
|
Your merge request shows you several panes of information:
|
|
|
|
|
|
Top-most is the request's title and description. These can be edited by pressing the yellow `Edit` button on the top-right corner of the page.
|
|
|
|
... | ... | @@ -74,7 +74,7 @@ The *Pipelines* tab provides a more detailed overview on the state of the variou |
|
|
|
|
|
Finally, the *Changes* tab shows the patch itself. This view may be restricted to changes made by a single commit by selecting the commit in the *Commits* tab. Moreover, one may view previous iterations of the merge request using the two drop-down menus at the top of the tab. To leave an inline comment click on a line in the patch.
|
|
|
|
|
|
### Modifying the validation pipeline
|
|
|
### 4. Modifying the validation pipeline
|
|
|
|
|
|
By default we run a selected few jobs in each merge request on the most common platforms.
|
|
|
|
... | ... | @@ -89,7 +89,7 @@ There are a few labels that you can apply to modify the configurations which are |
|
|
* ~"test-primops": Run test-primops, a testsuite which generates randomised tests for primops.
|
|
|
|
|
|
|
|
|
## Merging your merge request
|
|
|
## 5. Merging your merge request
|
|
|
|
|
|
We use @marge-bot to automatically rebase and merge branches to `master`.
|
|
|
After your merge request has been reviewed and approved, you can request that it be added to the merge queue by @-mentioning @reviewers. Your MR should be added to the merge queue within a day or two, assuming it passes CI and the commit history is in order (individually buildable commits with informative commit messages).
|
... | ... | @@ -102,6 +102,6 @@ As long as your MR satisfies the following, GitLab will batch your MR with other |
|
|
|
|
|
Each batch is an MR of its own, which must itself pass CI. You can expect GitLab to merge two or three batches per day.
|
|
|
|
|
|
### Rebasing
|
|
|
### 6. Rebasing
|
|
|
|
|
|
You generally do *not* need to rebase your MRs unless there are merge conflicts with `master`. GitLab will automatically rebase on top of `master` when batching MRs. |