github.com/openshift/source-to-image@v1.4.1-0.20240516041539-bf52fc02204e/CONTRIBUTING.md (about) 1 # Contributing Guide 2 3 ## Filing Bugs 4 5 Bug reports may be filed as an issue on GitHub, with the label `kind/bug`. 6 The label can be added by placing the [Prow](https://prow.svc.ci.openshift.org/command-help?repo=openshift%2Fsource-to-image) 7 command `/kind bug` in your issue. 8 9 A well-written bug report has the following format: 10 11 ```markdown 12 **Is this a feature request or bug?** 13 14 /kind bug 15 16 **What went wrong?** 17 18 Enter a description of what went wrong. 19 20 **Steps to reproduce:** 21 22 1. Step 1 23 2. Step 2 24 3. Step 3 25 26 **Expected results:** 27 28 Enter what you expected to happen. 29 30 **Actual results:** 31 32 Enter what actually occurred, including command line output 33 34 **Version:** 35 36 s2i: Enter output of `s2i version` 37 docker: Enter the output of `docker version` if you are using docker to build container images. 38 39 **Additional info:** 40 41 Add any relevant context here. 42 ``` 43 44 ## Submitting Feature Requests 45 46 Feature requests are likewise submitted as GitHub issues, with the `kind/feature` label. 47 The label can be added by placing the [Prow](https://prow.svc.ci.openshift.org/command-help?repo=openshift%2Fsource-to-image) 48 command `/kind feature` in your issue. 49 50 A well-written feature request has the following format: 51 52 ```markdown 53 **Is this a feature request or bug?** 54 55 /kind feature 56 57 **User Stories** 58 59 As a developer using source-to-image 60 I would like ... 61 So that ... 62 63 (you may add more than one story to provide further use cases to consider) 64 65 **Additional info:** 66 67 Add any relevant context or deeper description here. 68 ``` 69 70 ## Submitting a Pull Request 71 72 You can contribute to source-to-image by submitting a pull request ("PR"). 73 Any member of the OpenShift organization can review your PR and signal their approval with the 74 `/lgtm` command. Only approvers listed in the [OWNERS](OWNERS) file may add the `approved` label to 75 your PR. In order for PR to merge, it must have the following: 76 77 1. The `approved` label 78 2. The `lgtm` label 79 3. All tests passing in CI, which is managed by Prow. 80 81 If you are not a member of the OpenShift GitHub organization, an OpenShift team member will need to 82 add the `ok-to-test` label to your PR for our CI tests to run. 83 84 ### Feature or Bugfix PRs 85 86 Pull requests which implement a feature or fix a bug should consist of a single commit with the 87 full code changes. Commit messages should have the following structure: 88 89 ```text 90 <Title - under 50 characters> 91 92 <Body - under 100 characters per line> 93 94 <Footer> 95 ``` 96 97 The title is required, and should be under 50 characters long. This is a short description of your 98 change. 99 100 The body is optional, and may contain a longer description of the changes in the commit. Lines 101 should not exceed 100 characters in length for readability. 102 103 The footer is optional, and may contain information such as sign-off lines. If your code is related 104 to a GitHub issue, add it here with the text `Fixes xxx`. 105 106 ### Work In Progress PRs 107 108 Contributors who would like feedback but are still making code modifications can create "work in 109 progress" PRs by adding "WIP" to the PR title. Once work is done and ready for final review, please 110 remove "WIP" from your PR title and [squash your commits](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec). 111 112 ### Updating dependencies 113 114 Pull requests which update dependencies are an exception to the "one commit" rule. 115 To better track dependency changes, PRs with dependency updates should have the following structure: 116 117 1. A commit with changes to `go.mod` and `go.sum` declaring the new or updated dependencies. 118 2. A commit with updates to vendored code, with `bump(<modules>)` in the title: 119 1. If only a small number of modules are updated, list them in the parentheses. 120 Example: `bump(containers/image/v5):` 121 2. If several modules are updated, use `bump(*)` as the title. 122 3. Include a reason for updating dependencies in the commit body. 123 3. If necessary, add a commit with reactions to vendored code changes (ex - method signature 124 updates). 125 4. If necessary, add a commit with code that takes advantage of the newly vendored code. 126 127 See [HACKING.md](docs/HACKING.md#dependency-management) for more information on how to update dependencies.