github.com/redhat-appstudio/release-service@v0.0.0-20240507143925-083712697924/CONTRIBUTING.md (about)

     1  # Contributing
     2  
     3  Contributions of all kinds are welcome. In particular pull requests are appreciated. The authors and maintainers will endeavor to help walk you through any issues in the pull request discussion, so please feel free to open a pull request even if you are new to such things.
     4  
     5  ## Code of Conduct
     6  
     7  Our [company values](https://www.redhat.com/en/about/brand/standards/culture) guide us in our day-to-day interactions and decision-making. Our open source projects are no exception and they will define the standards for how to engage with the project through a [code of conduct](CODE_OF_CONDUCT.md). 
     8  
     9  Please, make sure you read both of them before contributing, so you can help us to maintain a healthy community.
    10  
    11  ## Requesting support
    12  
    13  Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.
    14  
    15  If you then still feel the need to ask a question and need clarification, we recommend the following:
    16  
    17  * Open an [Issue](/issues/new).
    18  * Provide as much context as you can about what you’re running into.
    19  * Provide project and platform versions (golang, operator-sdk, etc), depending on what seems relevant.
    20  * The community will then take care of the issue as soon as possible.
    21  
    22  ## Reporting Bugs
    23  
    24  We use GitHub issues to track bugs and errors. If you run into an issue with the project:
    25  
    26  * Open an [Issue](/issues/new).
    27  * Explain the behavior you would expect and the actual behavior.
    28  * Please provide as much context as possible and describe the reproduction steps that someone else can follow to recreate the issue on their own. This usually includes your code. For good bug reports you should isolate the problem and create a reduced test case.
    29  
    30  Once it’s filed:
    31  
    32  * The project team will label the issue accordingly.
    33  * A team member will try to reproduce the issue with your provided steps. If there are no reproduction steps or no obvious way to reproduce the issue, the team will ask you for those steps and mark the issue as `needs-reproducer`. Bugs with this tag will not be addressed until they are reproduced.
    34  * If the team is able to reproduce the issue, it will be marked `needs-fix` and left to be implemented by someone. Other labels can be used in addition to better describe the issue or its criticality.
    35  
    36  ## Requesting a feature
    37  
    38  Enhancement suggestions are tracked as [GitHub issues](/issues).
    39  
    40  - Use a **clear and descriptive title** for the issue to identify the suggestion.
    41  - Provide a **step-by-step description of the suggested enhancement** in as many details as possible.
    42  - Describe the current behavior, the expected one, and why you expect this behavior. At this point you can also list which alternatives do not work for you.
    43  - **Explain why this enhancement would be useful** to other users. You may also want to point out the other projects that solved it better and could serve as inspiration.
    44  
    45  ## Submitting changes
    46  
    47  Before contributing code or documentation to this project, make sure you read the following sections.
    48  
    49  ### Commit message formatting and standards
    50  
    51  The project follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification and enforces it using [gitlint](https://jorisroovers.com/gitlint/). The rules for this project are specified in the [.gitlint](.gitlint) config file. There is also a second rule file for the commit description that can be found in the [.github/gitlint directory](.github/gitlint).
    52  
    53  The commit message should contain an overall explanation about the change and the motivation behind it. Please note that mentioning a Jira ticket ID or a GitHub issue, isn't a replacement for that.
    54  
    55  A well formatted commit would look something like this:
    56  
    57  ```
    58  feat(issue-id): what this commit does
    59  
    60  Overall explanation of what this commit is achieving and the motivation behind it.
    61  
    62  Signed-off-by: Your Name <your-name@your-email.com>
    63  ```
    64  
    65  ### Signing commits
    66  
    67  This project also enforces GPG signed commits. More information on commit signing and how to do it can be found in the [git official docs](
    68  https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) or in [this GitHub guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). You can see whether or not the commit was successfully signed by the `Verified` bubble next to your commit in the GitHub UI or using `git log`.
    69  
    70  ### Pull Requests
    71  
    72  All changes must come from a pull request (PR) and cannot be directly committed. While anyone can engage in activity on a PR, pull requests are only approved by team members.
    73  
    74  Before a pull request can be merged:
    75  
    76  * The content of the PR has to be relevant to the PR itself
    77  * The contribution must follow the style guidelines of this project
    78  * Multiple commits should be used if the PR is complex and clarity can be improved, but they should still relate to a single topic
    79  * For code contributions, tests have to be added/modified to ensure the code works
    80  * There has to be at least one approval
    81  * The feature branch must be rebased so it contains the latest changes from the target branch
    82  * The CI has to pass successfully
    83  * Every comment has to be addressed and resolved
    84  
    85  ## Testing
    86  
    87  Tests are written using the *[Ginkgo](https://onsi.github.io/ginkgo/)* framework. Here are some general advices when writing tests:
    88  
    89  * When the global `Describe` doesn't add enough context to the tests, use a nested `Describe` or a `Context` to specify what this test alludes to. Contexts should always start with _When_ (ie. "_When calling the function Foo_")
    90  * Start the descriptions of `It` blocks in lowercase and try to be as descriptive as possible
    91  * Avoid ignoring errors. In other words, make sure all of them are caught and tested
    92  * Files ending with `_suite_test.go` are meant to store the code that is common for tests in the same directory and that will be executed before them. Use these files only if your test setup is big enough to justify it (ie. the suite file has more than the test suite name and the teardown)
    93  * When required, remember to add the `CRD`'s during the `envtest` setup, for instance: [release-service/release_suite_test.go at main · redhat-appstudio/release-service · GitHub](https://github.com/redhat-appstudio/release-service/blob/main/controllers/release/release_suite_test.go#L65) - remembering this saves a lot of time
    94  * After `Create()` or `Update()` objects, use `Get()` before making assurances as the object might be outdated. It is useful after `Delete()` to check if the client returns `errors.IsNotFound`
    95  * Some assurances are likely to require usage of `Eventually` blocks instead of or in addition to `Expect` blocks
    96  
    97  ### Useful links:
    98  
    99  Links that may be used as a starting point:
   100  
   101  * [Getting started with Ginkgo](https://onsi.github.io/ginkgo/#getting-started)
   102  * [Gomega reference doc](https://pkg.go.dev/github.com/onsi/gomega#section-readme)
   103  * [Writing controller tests](https://book.kubebuilder.io/cronjob-tutorial/writing-tests.html)
   104  * [Testing your Operator project](https://master.sdk.operatorframework.io/docs/building-operators/golang/testing/)
   105  
   106  Unofficial (but useful) links:
   107  
   108  * [Ginkgo and Gomega gotchas](https://medium.com/@william.la.martin/ginkgotchas-yeh-also-gomega-13e39185ec96)
   109  * [Effective Ginkgo/Gomega](https://medium.com/swlh/effective-ginkgo-gomega-b6c28d476a09)