2019-12-06 15:26:30 -05:00
# Contributing Guide
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
## Filing Bugs
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Bug reports may be filed as an issue on GitHub, with the label `kind/bug` .
The label can be added by placing the [Prow ](https://prow.svc.ci.openshift.org/command-help?repo=openshift%2Fsource-to-image )
command `/kind bug` in your issue.
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
A well-written bug report has the following format:
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
```markdown
**Is this a feature request or bug?**
2016-04-05 14:12:31 +02:00
2019-12-06 15:26:30 -05:00
/kind bug
2016-04-05 14:12:31 +02:00
2019-12-06 15:26:30 -05:00
**What went wrong?**
2016-04-05 14:12:31 +02:00
2019-12-06 15:26:30 -05:00
Enter a description of what went wrong.
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
**Steps to reproduce:**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
1. Step 1
2. Step 2
3. Step 3
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
**Expected results:**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Enter what you expected to happen.
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
**Actual results:**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Enter what actually occurred, including command line output
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
**Version:**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
s2i: Enter output of `s2i version`
docker: Enter the output of `docker version` if you are using docker to build container images.
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
**Additional info:**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Add any relevant context here.
```
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
## Submitting Feature Requests
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Feature requests are likewise submitted as GitHub issues, with the `kind/feature` label.
The label can be added by placing the [Prow ](https://prow.svc.ci.openshift.org/command-help?repo=openshift%2Fsource-to-image )
command `/kind feature` in your issue.
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
A well-written feature request has the following format:
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
```markdown
**Is this a feature request or bug?**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
/kind feature
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
**User Stories**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
As a developer using source-to-image
I would like ...
So that ...
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
(you may add more than one story to provide further use cases to consider)
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
**Additional info:**
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Add any relevant context or deeper description here.
```
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
## Submitting a Pull Request
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
You can contribute to source-to-image by submitting a pull request ("PR").
Any member of the OpenShift organization can review your PR and signal their approval with the
`/lgtm` command. Only approvers listed in the [OWNERS ](OWNERS ) file may add the `approved` label to
your PR. In order for PR to merge, it must have the following:
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
1. The `approved` label
2. The `lgtm` label
3. All tests passing in CI, which is managed by Prow.
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
If you are not a member of the OpenShift GitHub organization, an OpenShift team member will need to
add the `ok-to-test` label to your PR for our CI tests to run.
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
### Feature or Bugfix PRs
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
Pull requests which implement a feature or fix a bug should consist of a single commit with the
full code changes. Commit messages should have the following structure:
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
```text
<Title - under 50 characters>
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
<Body - under 100 characters per line>
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
<Footer>
```
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
The title is required, and should be under 50 characters long. This is a short description of your
change.
2015-02-27 13:43:05 +01:00
2019-12-06 15:26:30 -05:00
The body is optional, and may contain a longer description of the changes in the commit. Lines
should not exceed 100 characters in length for readability.
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
The footer is optional, and may contain information such as sign-off lines. If your code is related
to a GitHub issue, add it here with the text `Fixes xxx` .
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
### Work In Progress PRs
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
Contributors who would like feedback but are still making code modifications can create "work in
progress" PRs by adding "WIP" to the PR title. Once work is done and ready for final review, please
remove "WIP" from your PR title and [squash your commits ](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec ).
2015-05-26 11:34:53 +02:00
2019-12-06 15:26:30 -05:00
### Updating dependencies
Pull requests which update dependencies are an exception to the "one commit" rule.
To better track dependency changes, PRs with dependency updates should have the following structure:
1. A commit with changes to `go.mod` and `go.sum` declaring the new or updated dependencies.
2. A commit with updates to vendored code, with `bump(<modules>)` in the title:
1. If only a small number of modules are updated, list them in the parentheses.
Example: `bump(containers/image/v5):`
2. If several modules are updated, use `bump(*)` as the title.
3. Include a reason for updating dependencies in the commit body.
3. If necessary, add a commit with reactions to vendored code changes (ex - method signature
updates).
4. If necessary, add a commit with code that takes advantage of the newly vendored code.
See [HACKING.md ](docs/HACKING.md#dependency-management ) for more information on how to update dependencies.
