Skip to content

Latest commit

 

History

History
74 lines (51 loc) · 3.09 KB

CONTRIBUTING.md

File metadata and controls

74 lines (51 loc) · 3.09 KB

Contributing to oc-mirror

Welcome to our contributing guide! We are eager to receive contributions of all types. Ways to contribute include:

What should I know before I get started?

oc-mirror design

How can I contribute?

Reporting Bugs

Please submit bug reports as GitHub Issues. When submitting bug reports, please include:

  1. A concise title
  2. Log snippets
  3. The command used to execute the task.
  4. The imageset-config used in the execution (if applicable)
  5. Use our template

Requesting Enhancements

  1. A concise title
  2. A concise description of the modification
  3. The conditions under which the modification would be relevant
  4. The desired outcome of the modification
  5. Provide step-by-step instructions of the enhancement
  6. Explain the difference between enhancement and current functionality
  7. Explain enhancement use cases
  8. Explain current workaround/alternatives without the enhancement

Your First Code Contribution

Getting Started

Please refer to the developer docs for information on getting started with developing on oc-mirror.

Pull Requests

When submitting pull requests, please ensure the following:

  1. Include unit tests if applicable
  2. Update ./docs if applicable
  3. Update ./data if modifying schema
  4. Follow our styleguides
  5. Use our template

Docs Contributions

We will always need better docs! You can contribute to our ./docs in the following ways:

  1. Markdown-formatted tutorials for using oc-mirror in different scenarios.
  2. Enhanced Developer/hacking docs
  3. Linux man style docs

Testing

To test basic functionality locally, we have developed an end to end test. Please use make test-e2e.

Functional testing of oc-mirror is difficult. Building a comprehensive test matrix is nearly impossible. If we do some thought experiments about how oc-mirror works, we can see the complexity quickly developing:

  1. If over the lifecycle of differential use of oc-mirror, we have synchronized 3 openshift releases between 3 imagesets and we specify a latest openshift release for our next imageset, which prior openshift versions will have upgradeability to the incoming imageset with the latest openshift release? The answer should be that all previous downloads have an upgrade path to the highest incoming version because oc-mirror should have pulled any intermediary openshift versions needed. Is that the case? Test it out and submit an issue if it does something unexpected!