docs: enhance contributors development setup guide

Linted all the markdown files but noticed they have outdated content,
example: installing openebs 3.X and operator lite
Improve development setup guide, including the nixos-shell k3s docs

Signed-off-by: Tiago Castro <[email protected]>

Author: tiagolobocastro

.github/workflows/build_and_push.yml

@@ -97,7 +97,7 @@ jobs:
         run: |
           make bootstrap
           make helm-install
-          CI_HACK_SUDO="true" make integration-test
+          make integration-test
 
       - name: Upload Integration Test Coverage Report
         uses: codecov/codecov-action@v4

.github/workflows/pull_request.yml

@@ -112,7 +112,7 @@ jobs:
         run: |
           make bootstrap
           make helm-install
-          CI_HACK_SUDO="true" make integration-test
+          make integration-test
 
       - name: Upload Integration Test Coverage Report
         uses: codecov/codecov-action@v4

CODE_OF_CONDUCT.md

@@ -1,8 +1,10 @@
 # Code of Conduct
+
 <BR>
 
 ## Umbrella Project
+
 OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files.
 <BR>
 
-This project follows the [OpenEBS Code of Conduct](https://github.com/openebs/community/blob/HEAD/CODE_OF_CONDUCT.md)
+This project follows the [OpenEBS Code of Conduct](https://github.com/openebs/community/blob/HEAD/CODE_OF_CONDUCT.md)

CONTRIBUTING.md

@@ -1,53 +1,55 @@
 # Contributing Guidelines
-<BR>
+
+<br>
 
 ## Umbrella Project
+
 OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files.
-<BR>
+<br>
 
 This project follows the [OpenEBS Contributor Guidelines](https://github.com/openebs/community/blob/HEAD/CONTRIBUTING.md)
 
-# Contributing to OpenEBS Dynamic Local PV Provisioner
+## Contributing to OpenEBS Dynamic Local PV Provisioner
 
 OpenEBS uses the standard GitHub pull requests process to review and accept contributions.  There are several areas that could use your help. For starters, you could help in improving the sections in this document by either creating a new issue describing the improvement or submitting a pull request to this repository. The issues for the various OpenEBS components (including this repository) are maintained in [openebs/openebs](https://github.com/openebs/openebs/issues) repository.
 
 * If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute).
 * If you have documentation improvement ideas, go ahead and create a pull request. See [Pull Request checklist](#pull-request-checklist).
 * If you would like to make code contributions, please start with [Setting up the Development Environment](#setting-up-your-development-environment).
-* If you would like to work on something more involved, please connect with the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community).
+* If you would like to work on something more involved, please connect with the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/HEAD/community).
 
-## Steps to Contribute
+### Steps to Contribute
 
 OpenEBS is an Apache 2.0 Licensed project and all your commits should be signed with Developer Certificate of Origin. See [Sign your work](#sign-your-work).
 
 * Find an issue to work on or create a new issue. The issues are maintained at [openebs/openebs](https://github.com/openebs/openebs/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/openebs/labels/good%20first%20issue).
 * Claim your issue by commenting your intent to work on it to avoid duplication of efforts.
 * Fork the repository on GitHub.
-* Create a branch from where you want to base your work (usually master).
+* Create a branch from where you want to base your work (usually `develop`).
 * Make your changes. If you are working on code contributions, please see [Setting up the Development Environment](#setting-up-your-development-environment).
 * Relevant coding style guidelines are the [Go Code Review Comments](https://code.google.com/p/go-wiki/wiki/CodeReviewComments) and the _Formatting and style_ section of Peter Bourgon's [Go: Best Practices for Production Environments](http://peter.bourgon.org/go-in-production/#formatting-and-style).
 * Commit your changes by making sure the commit messages convey the need and notes about the commit.
 * Push your changes to the branch in your fork of the repository.
 * Submit a pull request to the original repository. See [Pull Request checklist](#pull-request-checklist).
 
-## Pull Request Checklist
+### Pull Request Checklist
 
-* Rebase to the current master branch before submitting your pull request.
+* Rebase to the current `develop` branch before submitting your pull request.
 * Commits should be as small as possible. Each commit should follow the checklist below:
-  - For code changes, add tests relevant to the fixed bug or new feature.
-  - Pass the compile and tests - includes spell checks, formatting, etc.
-  - Commit header (first line) should convey what changed.
-  - Commit body should include details such as why the changes are required and how the proposed changes.
-  - DCO Signed.
-* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/master/community).
+  * For code changes, add tests relevant to the fixed bug or new feature.
+  * Pass the compile and tests - includes spell checks, formatting, etc.
+  * Commit header (first line) should convey what changed.
+  * Commit body should include details such as why the changes are required and how the proposed changes.
+  * DCO Signed.
+* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the OpenEBS Contributors. See [OpenEBS Community](https://github.com/openebs/openebs/tree/HEAD/community).
 
-## Sign your work
+### Sign your work
 
-We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS project. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/master/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
+We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS project. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please read [dcofile](https://github.com/openebs/openebs/blob/HEAD/contribute/developer-certificate-of-origin). If you can certify it, then just add a line to every git commit message:
 
 Please certify it by just adding a line to every git commit message. Any PR with Commits which does not have DCO Signoff will not be accepted:
 
-```
+```text
   Signed-off-by: Random J Developer <[email protected]>
 ```
 
@@ -56,38 +58,45 @@ If you set your `user.name` and `user.email` in git config, you can sign your co
 
 You can also use git [aliases](https://git-scm.com/book/tr/v2/Git-Basics-Git-Aliases) like `git config --global alias.ci 'commit -s'`. Now you can commit with `git ci` and the commit will be signed.
 
-## Setting up your Development Environment
+### Setting up your Development Environment
 
 This project is implemented using Go and uses the standard golang tools for development and build. In addition, this project heavily relies on Docker and Kubernetes. It is expected that the contributors:
-- are familiar with working with Go;
-- are familiar with Docker containers;
-- are familiar with Kubernetes and have access to a Kubernetes cluster or Minikube to test the changes.
+
+* are familiar with working with Go;
+* are familiar with Docker containers;
+* are familiar with Kubernetes and have access to a Kubernetes cluster or Minikube to test the changes.
 
 For setting up a Development environment on your local host, see the detailed instructions [here](./docs/developer.md).
 
-## Reviews against Pull Requests
+### Reviews against Pull Requests
 
 A PR can be reviewed by both core as well as external contributors. Below can be referred to during reviews:
-- contributor should fix all the linting issues raised by the lint tools integrated with CI (`make test`)
-- contributor should try to implement relevant golang based unit tests for the fix/enhancement (`make test`)
-- contributor should try to rework on the review comments as much as possible
-- a review comment can be taken up later if it falls under any of the following categories
-  - if the review comment talks about a new idiom or code pattern that is not currently in use by this repo
-  - if the review comment talks about the need to implement integration test corresponding to the fix/enhancement
-  - if contributor as well as reviewer agree that it can be addressed in a different PR
-- contributor should follow below pattern in code comments when some rework needs to be done at a later point:
+
+* contributor should fix all the linting issues raised by the lint tools integrated with CI (`make test`)
+* contributor should try to implement relevant golang based unit tests for the fix/enhancement (`make test`)
+* contributor should try to rework on the review comments as much as possible
+* a review comment can be taken up later if it falls under any of the following categories
+  * if the review comment talks about a new idiom or code pattern that is not currently in use by this repo
+  * if the review comment talks about the need to implement integration test corresponding to the fix/enhancement
+  * if contributor as well as reviewer agree that it can be addressed in a different PR
+* contributor should follow below pattern in code comments when some rework needs to be done at a later point:
+
 ```go
 // TD:        -- indicates technical debt
 ```
+
 ```go
 // NBDD:      -- indicates needs integration tests in BDD format _(i.e. ginkgo tests)_
 ```
+
 ```go
 // TD: SMALL  -- indicates few/similar code changes & hence less impact
 ```
+
 ```go
 // TD: MEDIUM -- indicates code changes at multiple files & may impact certain feature
 ```
+
 ```go
 // TD: LARGE  -- indicates code changes at multiple files & has impact on more than one features
 ```

GOVERNANCE.md

@@ -1,8 +1,10 @@
 # Governance
+
 <BR>
 
 ## Umbrella Project
+
 OpenEBS is an "umbrella project". Every project, repository and file in the OpenEBS organization adopts and follows the policies found in the Community repo umbrella project files.
 <BR>
 
-This project follows the [OpenEBS Governance](https://github.com/openebs/community/blob/HEAD/GOVERNANCE.md)
+This project follows the [OpenEBS Governance](https://github.com/openebs/community/blob/HEAD/GOVERNANCE.md)

Makefile

@@ -124,6 +124,11 @@ bootstrap:
 clean:
 	go clean -testcache
 	rm -rf bin
+	./ci/ci-test.sh clean
+	chmod -R u+w ${GOPATH}/bin/${PROVISIONER_LOCALPV} 2>/dev/null || true
+	chmod -R u+w ${GOPATH}/pkg/* 2>/dev/null || true
+	rm -rf ${GOPATH}/bin/${PROVISIONER_LOCALPV}
+	rm -rf ${GOPATH}/pkg/*
 
 .PHONY: test
 test: format vet

README.md

@@ -9,24 +9,25 @@
 <img width="300" align="right" alt="OpenEBS Logo" src="https://raw.githubusercontent.com/cncf/artwork/master/projects/openebs/stacked/color/openebs-stacked-color.png" xmlns="http://www.w3.org/1999/html">
 
 <p align="justify">
-<strong>OpenEBS Dynamic Local PV provisioner</strong> can be used to dynamically provision 
-Kubernetes Local Volumes using different kinds of storage available on the Kubernetes nodes. 
+<strong>OpenEBS Dynamic Local PV provisioner</strong> can be used to dynamically provision
+Kubernetes Local Volumes using different kinds of storage available on the Kubernetes nodes.
 <br>
 </p>
 
 ## Project Status: GA
 
-Local Persistent Volumes are great for distributed cloud native data services that can handle resiliency and availability and expect low-latency access to the storage. Local Persistent Volumes can be provisioned using the hostpath, NVMe or PCIe based SSDs, Hard Disks or on top of other filesystems like ZFS, LVM. 
+Local Persistent Volumes are great for distributed cloud native data services that can handle resiliency and availability and expect low-latency access to the storage. Local Persistent Volumes can be provisioned using the hostpath, NVMe or PCIe based SSDs, Hard Disks or on top of other filesystems like ZFS, LVM.
 
 Some of the targetted applications are:
+
 - Distributed SQL Databases like PostgreSQL
 - Distributed No-SQL Databases like MongoDB, Cassandra
 - Distributed Object Storages like MinIO (distributed mode)
-- Distributed Streaming services like Apache Kakfa, 
+- Distributed Streaming services like Apache Kakfa,
 - Distributed Logging and search services like ElasticSearch, Solr
 - AI/ML workloads
 
-## Overview 
+## Overview
 
 Kubernetes Local persistent volumes allows users to access local storage through the
 standard PVC interface in a simple and portable way. The PV contains node
@@ -56,21 +57,21 @@ Head over to the [CONTRIBUTING.md](./CONTRIBUTING.md) page.
 
 ## Roadmap
 
-Find the Dynamic Local PV roadmap items at the [OpenEBS Roadmap page](https://github.com/openebs/openebs/blob/master/ROADMAP.md#dynamic-local-pvs).
+Find the Dynamic Local PV roadmap items at the [OpenEBS Roadmap page](https://github.com/openebs/openebs/blob/HEAD/ROADMAP.md#dynamic-local-pvs).
 
 ## OpenEBS Adopters
 
-Check out the list of organizations and users who have chosen OpenEBS to run their stateful workloads, over at the [OpenEBS Adopters page](https://github.com/openebs/openebs/blob/master/ADOPTERS.md).
+Check out the list of organizations and users who have chosen OpenEBS to run their stateful workloads, over at the [OpenEBS Adopters page](https://github.com/openebs/openebs/blob/HEAD/ADOPTERS.md).
 
 ## Community, discussion, and support
 
-Learn how to engage with the OpenEBS community on the [community page](https://github.com/openebs/openebs/tree/master/community).
+Learn how to engage with the OpenEBS community on the [community page](https://github.com/openebs/openebs/tree/HEAD/community).
 
 You can reach the maintainers of this project at:
 
-- [Kubernetes Slack](http://slack.k8s.io/) channels: 
-      * [#openebs](https://kubernetes.slack.com/messages/openebs/)
-      * [#openebs-dev](https://kubernetes.slack.com/messages/openebs-dev/)
+- [Kubernetes Slack](http://slack.k8s.io/) channels:
+  - [#openebs](https://kubernetes.slack.com/messages/openebs/)
+  - [#openebs-dev](https://kubernetes.slack.com/messages/openebs-dev/)
 - [Mailing List](https://lists.cncf.io/g/cncf-openebs-users)
 
 ### Code of conduct
@@ -80,10 +81,11 @@ Participation in the OpenEBS community is governed by the [CNCF Code of Conduct]
 ## Inspiration/Credit
 
 OpenEBS Local PV has been inspired by the prior work done by the following the Kubernetes projects:
-- https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner/tree/master/examples/hostpath-provisioner
-- https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner
-- https://github.com/rancher/local-path-provisioner
 
+- <https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner/tree/HEAD/examples/hostpath-provisioner>
+- <https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner>
+- <https://github.com/rancher/local-path-provisioner>
 
 ## License Compliance
+
 [![FOSSA Status](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Fopenebs%2Fdynamic-localpv-provisioner.svg?type=large&issueType=license)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fopenebs%2Fdynamic-localpv-provisioner?ref=badge_large&issueType=license)

RELEASE.md

@@ -1,9 +1,11 @@
 # Release Process
+
 OpenEBS Dynamic Local PV Provisioner follows a monthly release cadence. The scope of the release is determined by contributor availability. The scope is published in the [Release Tracker Projects](https://github.com/orgs/openebs/projects).
 
 ## Release Candidate Verification Checklist
 
 Every release has release candidate builds that are created starting from the third week into the release. These release candidate builds help to freeze the scope and maintain the quality of the release. The release candidate builds will go through:
+
 - Platform Verification
 - Regression and Feature Verification Automated tests.
 - Exploratory testing by QA engineers
@@ -31,10 +33,11 @@ Once the release is triggered, Github Actions release workflow has to be monitor
 Images for the different components are published at the following location:
 
 - Dynamic LocalPV Provisioner <br />
-    https://quay.io/repository/openebs/provisioner-localpv?tab=tags <br />
-    https://hub.docker.com/r/openebs/provisioner-localpv/tags <br />
+    <https://quay.io/repository/openebs/provisioner-localpv?tab=tags> <br />
+    <https://hub.docker.com/r/openebs/provisioner-localpv/tags> <br />
 
 Once a release is created, update the release description with the changelog mentioned in `changelog/v1.9.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `develop` with the following details:
+
 1. update the changelog from `changelog/v1.9.x` to `CHANGELOG.md`
 2. If a release is not an RC tag then PR should include the changes to remove `changelog/v1.9.x` folder.
 3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v1.9.x` which are already mentioned in `CHANGELOG.md` as part of step number 1.

ci/ci-test.sh

@@ -135,19 +135,11 @@ run_test_suit() {
   echo "running ginkgo test case with coverage"
 
   # --focus="TEST HOSTPATH EXT4 QUOTA LOCAL PV WITH UNSUPPORTED FILESYSTEM"
-  if [ -n "${CI_HACK_SUDO:-}" ]; then
-    if ! sudo -E env "PATH=${PATH}" ginkgo -v -coverprofile="integration_coverage.txt" -covermode=atomic; then
-      return 0
-    fi
-  else
-    if ginkgo -v -coverprofile="integration_coverage.txt" -covermode=atomic; then
-      return 0
-    fi
+  if ! sudo -E env "PATH=${PATH}" ginkgo -v -coverprofile="integration_coverage.txt" -covermode=atomic; then
+    dump_logs
+    [ "$CLEAN_AFTER" = "true" ] && cleanup
+    exit 1
   fi
-
-  dump_logs
-  [ "$CLEAN_AFTER" = "true" ] && cleanup
-  exit 1
 }
 
 run() {