-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] added contributing.md file to assist new contributors #946
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: kernelpanic77 <[email protected]>
Hi @kernelpanic77. Thanks for your PR. I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kernelpanic77. I know this is WIP but I had a few initial suggestions.
docs/CONTRIBUTING.md
Outdated
(#testing-your-changes) | ||
- [Signing-off on Commits](#signing-off-on-commits) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accidentally duplicated lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, updated.
docs/CONTRIBUTING.md
Outdated
git remote -v | ||
``` | ||
|
||
**6.** Always take a pull from the upstream repository to your master branch to keep it at par with the main project (updated repository). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should avoid focusing on how to set up git repositories for the contributing guide -- assume the user has cloned a suitable repo to their local machine and wants to begin writing code for it. To this end, focus on
- What's required
- What the flow is for starting/debugging/testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I have added a "testing your changes" section for describing the general workflow of debugging and testing.
docs/CONTRIBUTING.md
Outdated
git checkout -b <your_branch_name> | ||
``` | ||
|
||
**8.** Start the minikube cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be scoped to a "developing on minikube" section; we don't require developers use minikube. In addition, how to start/configure minikube is out of scope for this article except where required (e.g. if we needed a specific amount of memory)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @amisevsk! I have added that the steps are specifically for developing the devworkspace-operator on a minikube cluster. Should I add anything else ?
docs/CONTRIBUTING.md
Outdated
**12.** Install the dependencies for running the devworkspace-operator in your cluster. | ||
|
||
``` | ||
make install | ||
``` | ||
|
||
**13.** Scale down the replicas of pods to 0. | ||
|
||
``` | ||
kubectl patch deployment/devworkspace-controller-manager --patch "{\"spec\":{\"replicas\":0}}" -n $NAMESPACE | ||
``` | ||
|
||
**14.** Run the devworkspace-operator. | ||
|
||
``` | ||
make run | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Structurally, this should appear in a section like "running the controller locally"; this is not the only way to contribute so we shouldn't present it as such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kernelpanic77 looking great so far 😎 In addition to @amisevsk's review, left some minor comments and potential suggestions.
After these comments are addressed, it might be worth adding a section on developing the webhook. IIRC, this process involves:
- Make a change to the webhook
- Ensure the DWO_IMG environment variable points to your container image repository, eg.
export DWO_IMG=quay.io/aobuchow/dwo-webhook:next
- Run
make docker restart
(assuming DWO is already deployed to the cluster, otherwisemake docker install)
- Wait for the webhook deployment to update with your image that contains your latest changes.
There may be a better way to develop the webhook, but this is generally the flow that I've performed.
docs/CONTRIBUTING.md
Outdated
|
||
Follow the following instructions to start contributing. | ||
|
||
**1.** Fork [this](https://github.com/devfile/devworkspace-operator) repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor, but I would change this to Fork the [DevWorkspace Operator](https://github.com/devfile/devworkspace-operator) repository
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kernelpanic77 looking great so far sunglasses In addition to @amisevsk's review, left some minor comments and potential suggestions.
After these comments are addressed, it might be worth adding a section on developing the webhook. IIRC, this process involves:
Thanks @AObuchow. This makes sense, I'll add a specific sub section for testing and developing webhooks in the "testing your changes" section.
- Make a change to the webhook
- Ensure the DWO_IMG environment variable points to your container image repository, eg.
export DWO_IMG=quay.io/aobuchow/dwo-webhook:next
- Run
make docker restart
(assuming DWO is already deployed to the cluster, otherwisemake docker install)
- Wait for the webhook deployment to update with your image that contains your latest changes.
There may be a better way to develop the webhook, but this is generally the flow that I've performed.
I have not contributed to developing webhooks yet 😅 , so this looks right to me. @amisevsk @ibuziuk would you like to add any steps to the process specified by @AObuchow.
docs/CONTRIBUTING.md
Outdated
export NAMESPACE="devworkspace-controller" | ||
``` | ||
|
||
**11.** Install the kubernetes certificate management controller to generate and manage TLS certificates for your cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth noting that the cert manager is required only for Kubernetes, so if a "developing on minikube" section of this documented is created, this should probably be specific to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cert-manager is required for all deployments on Kubernetes, not just minikube.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docs/CONTRIBUTING.md
Outdated
**11.** Install the kubernetes certificate management controller to generate and manage TLS certificates for your cluster. | ||
|
||
``` | ||
make install cert-manager. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, making the change. make install_cert_manager
seems right to me as well.
docs/CONTRIBUTING.md
Outdated
make install | ||
``` | ||
|
||
**13.** Scale down the replicas of pods to 0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "Scale down the controller manager deployment's pods to 0."?
The reason this step is necessary is that only 1 controller manager can be run at a time (otherwise their operations will conflict/"fight" with each other), and if we are running the controller locally then we need to ensure the controller is not running on the cluster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted 👍 .
docs/CONTRIBUTING.md
Outdated
make run | ||
``` | ||
|
||
This will run the devworkspace-controller in your local cluster (minikube/openshift). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, this will make the devworkspace-controller run locally on your system (not on your local cluster).
I would remove the mention of "(minikube/openshift)" and, as @amisevsk mentioned, make this appear in a section on running the controller locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted 👍 .
docs/CONTRIBUTING.md
Outdated
git commit -s -m "<commit subject>" | ||
``` | ||
|
||
**17.** While you are working on your branch, other developers may update the `master` branch with their branch. This action means your branch is now out of date with the `master` branch and missing content. So to fetch the new changes, follow along: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @amisevsk mentioned, I would omit instructions on setting up git/developing with git. With that being said, for DWO the master branch is called main
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I have removed the git/developing instructions for commit instructions.
docs/CONTRIBUTING.md
Outdated
|
||
- [Contributing to Devworkspace-Operator](#contributing-to-devworkspace-operator) | ||
- [Before You Get Started](#before-you-get-started) | ||
- [Code of Conduct](#code-of-conduct) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if you had ideas for the "For Newcomers" section, but if you end up omitting it, it may be worth moving the code of conduct section to the end of this document (or at least, after the "How to Contribute" section).
This is just so that the contributing instructions are immediately visible (as the Code of Conduct section could be a bit lengthy).
Also, if you're looking for inspiration for a code of conduct, here's one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, here's an even better Code of Conduct from the devfile API repo: https://github.com/devfile/api/blob/main/CODE_OF_CONDUCT.md. It's probably worth making another, separate file for the code of conduct and linking to it in the CONTRIBUTING.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am actually omitting the newcomer's section. As it just doesn't seem an immediate requirement for now.
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kernelpanic77 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kernelpanic77 thank you for your interest in the project. Would you be able to address the review comments and rebase?
Co-authored-by: Angel Misevski <[email protected]>
Co-authored-by: Angel Misevski <[email protected]>
Signed-off-by: kernelpanic77 <[email protected]>
Co-authored-by: Angel Misevski <[email protected]>
Co-authored-by: Angel Misevski <[email protected]>
Signed-off-by: kernelpanic77 <[email protected]>
Signed-off-by: kernelpanic77 <[email protected]>
@kernelpanic77 I think something went wrong with your rebase, this PR is now showing as containing 111 commits, changing 322 files. |
@amisevsk I have fixed the issue. I changed the base branch to main. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kernelpanic77 Awesome work 😎 🙏 Looking forward to getting this merged.
I left some comments, most of the things I wrote are minor nitpicks :P
docs/CONTRIBUTING.md
Outdated
@@ -0,0 +1,126 @@ | |||
# Contributing to Devworkspace-Operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with the README, the project should be referred to as "DevWorkspace Operator". @amisevsk correct me if I am wrong.
Hey @AObuchow ! I have addressed the changes requested by you. Please have a look. Let's get this merged 💯 |
Signed-off-by: kernelpanic77 [email protected]
What does this PR do?
This PR completes the addition of the contributing guidelines to the DWO repository.
What issues does this PR fix or reference?
#935
Is it tested? How?
PR Checklist
/test v8-devworkspace-operator-e2e, v8-che-happy-path
to trigger)v8-devworkspace-operator-e2e
: DevWorkspace e2e testv8-che-happy-path
: Happy path for verification integration with Che