You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+43-3Lines changed: 43 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,9 +21,11 @@ There are 2 types of issues:
21
21
22
22
This section describes the guidelines for contributing code / docs to Hyperlight.
23
23
24
-
### Pull Requests
24
+
### Opening a New Pull Request
25
25
26
-
All contributions come through pull requests. To submit a proposed change, we recommend following this workflow:
26
+
All contributions come through pull requests.
27
+
28
+
To submit a proposed change, we recommend following this workflow:
27
29
28
30
1. Make sure there's an issue (bug or proposal) raised, which sets the expectations for the contribution you are about to make.
29
31
2. Fork the relevant repo and create a new branch
@@ -39,12 +41,50 @@ All contributions come through pull requests. To submit a proposed change, we re
39
41
40
42
A good way to communicate before investing too much time is to create a "Work-in-progress" PR and share it with your reviewers. The standard way of doing this is to add a "[WIP]" prefix in your PR's title and open the pull request as a draft.
41
43
44
+
### Pull Request Lifecycle
45
+
46
+
Hyperlight leverages a [PROW](https://docs.prow.k8s.io/) deployment to manage the lifecycle of pull requests.
47
+
This section describes requirements needed for the system to successfully merge pull requests and also commands that can be used to interact with the system.
48
+
49
+
#### Merge Requirements
50
+
51
+
[Tide](https://docs.prow.k8s.io/docs/components/core/tide/) is a component of the PROW deployment that enforces merge requirements on pull requests and handles mering of eligible pull requests.
52
+
53
+
The following **requirements** must be met before a pull request can be merged:
54
+
55
+
- The following labels must be present on the pull request:
56
+
-`lgtm`: 'Looks good to me' approval from at least one reviewer.
57
+
-`approved`: 'Approved' approval from at least one maintainer.
58
+
- The following labels must *not* be present on the pull request:
59
+
-`do-not-merge/hold`: 'Do not merge' label indicating a review has requested the pull request not be merged.
60
+
-`do-not-merge/work-in-progress`: 'Do not merge' label indicating the pull request is not ready to be merged.
61
+
-`needs-rebase`: A label indicating the pull request needs to be rebased to avoid conflicts.
62
+
63
+
#### Interacting With Pull Requests
64
+
65
+
- 'Looks Good To Me' (LGTM) approval can be given by adding a comment with `/lgtm` to the pull request.
66
+
LGTM approval can be given GitHub org members (excluding the author of the pull request).
67
+
`/lgtm cancel` can be used to revoke the LGTM approval.
68
+
- 'Approved' approval can be given by adding a comment with `/approve` to the pull request.
69
+
Pull Request approval is reserved for code owners declared in the `OWNERS` file.
70
+
Note: pushing new changes to a pull request will not cancel the approval.
71
+
`/approve cancel` can be used to revoke the approval.
72
+
- 'Do Not Merge' labels are used to prevent pull requests from merging.
73
+
`/hold {reason}` can be added to comments to add the `do-not-merge/hold` label.
74
+
`/hold cancel` can be used to remove the `do-not-merge/hold` label.
75
+
- 'tide' labels can be used to change how the pull request will be merged.
76
+
`/label tide/merge-method-merge` will merge the pull request using the 'merge' (default) method.
77
+
`/label tide/merge-method-squash` will merge the pull request using the 'squash' method.
78
+
`/label tide/merge-method-rebase` will merge the pull request using the 'rebase' method.
79
+
`/remove-label tide/merge-method-{method}` will remove the merge method label.
80
+
42
81
### Developer Certificate of Origin: Signing your work
43
82
44
83
#### Every commit needs to be signed
45
84
46
85
The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Here is the full text of the [DCO](https://developercertificate.org/), reformatted for readability:
47
-
```
86
+
87
+
```text
48
88
By making a contribution to this project, I certify that:
49
89
50
90
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
0 commit comments