diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 0f2e4df44..3e1551424 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,7 +1,7 @@ **What this PR does**: diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index bc5d2bf25..95cb000b6 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -17,7 +17,7 @@ on: create: push: branches: - - 'master' + - 'develop' - 'v*' paths-ignore: - '*.md' @@ -85,7 +85,7 @@ jobs: run: | BRANCH="${GITHUB_REF##*/}" CI_TAG=${BRANCH#v}-ci - if [ ${BRANCH} = "master" ]; then + if [ ${BRANCH} = "develop" ]; then CI_TAG="ci" fi echo "TAG=${CI_TAG}" >> $GITHUB_ENV @@ -122,7 +122,7 @@ jobs: run: | BRANCH="${GITHUB_REF##*/}" CI_TAG=${BRANCH#v}-ci - if [ ${BRANCH} = "master" ]; then + if [ ${BRANCH} = "develop" ]; then CI_TAG="ci" fi echo "TAG=${CI_TAG}" >> $GITHUB_ENV @@ -136,6 +136,7 @@ jobs: images: | ${{ env.IMAGE_ORG }}/cstor-csi-driver quay.io/${{ env.IMAGE_ORG }}/cstor-csi-driver + ghcr.io/${{ env.IMAGE_ORG }}/cstor-csi-driver tag-latest: false tag-custom-only: true tag-custom: | @@ -170,6 +171,13 @@ jobs: username: ${{ secrets.QUAY_USERNAME }} password: ${{ secrets.QUAY_TOKEN }} + - name: Login to GHCR + uses: docker/login-action@v1 + with: + registry: ghcr.io + username: ${{ github.actor }} + password: ${{ secrets.GITHUB_TOKEN }} + - name: Build & Push Image uses: docker/build-push-action@v2 with: diff --git a/.github/workflows/pull_request.yml b/.github/workflows/pull_request.yml index 7968766f4..e5afd664d 100644 --- a/.github/workflows/pull_request.yml +++ b/.github/workflows/pull_request.yml @@ -17,8 +17,8 @@ name: ci on: pull_request: branches: - # on pull requests to master and release branches - - 'master' + # on pull requests to develop and release branches + - 'develop' - 'v*' paths-ignore: - '*.md' @@ -82,7 +82,7 @@ jobs: run: | BRANCH="${GITHUB_REF##*/}" CI_TAG=${BRANCH#v}-ci - if [ ${BRANCH} = "master" ]; then + if [ ${BRANCH} = "develop" ]; then CI_TAG="ci" fi echo "TAG=${CI_TAG}" >> $GITHUB_ENV diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 1980acc4a..e71e2fdea 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -52,6 +52,7 @@ jobs: images: | ${{ env.IMAGE_ORG }}/cstor-csi-driver quay.io/${{ env.IMAGE_ORG }}/cstor-csi-driver + ghcr.io/${{ env.IMAGE_ORG }}/cstor-csi-driver tag-latest: true tag-semver: | {{version}} @@ -85,6 +86,13 @@ jobs: username: ${{ secrets.QUAY_USERNAME }} password: ${{ secrets.QUAY_TOKEN }} + - name: Login to GHCR + uses: docker/login-action@v1 + with: + registry: ghcr.io + username: ${{ github.actor }} + password: ${{ secrets.GITHUB_TOKEN }} + - name: Build & Push Image uses: docker/build-push-action@v2 with: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d3f234577..79482a91d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,7 +6,7 @@ You can contribute to cstor-csi driver by filling an issue at [openebs/cstor-csi * If you want to file an issue for bug or feature request, please see [Filing an issue](#filing-an-issue) * If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute) and code standard(code-standard.md). -* 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) ## Filing an issue ### Before filing an issue @@ -51,7 +51,7 @@ For setting up a development environment on your local machine, see the detailed * Find an issue to work on or create a new issue. The issues are maintained at [openebs/cstor-csi](https://github.com/openebs/cstor-csi/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/cstor-csi/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). * Commit your changes by making sure the commit messages convey the need and notes about the commit. * Please make sure than your code is aligned with the standard mentioned at [code-standard](docs/code-standard.md). * Verify that your changes pass `make lint` and `make test` @@ -59,7 +59,7 @@ For setting up a development environment on your local machine, see the detailed * Submit a pull request to the original repository. See [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. - Commit header (first line) should convey what changed @@ -88,12 +88,12 @@ For setting up a development environment on your local machine, see the detailed * `style` - formatting, missing semicolons, linting fix, etc; no significant production code changes * `test` - adding missing tests, refactoring tests; no production code change * `refactor` - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes - * `cherry-pick` - if PR is merged in the master branch and raised to release branch(like v1.9.x) + * `cherry-pick` - if PR is merged in the develop branch and raised to release branch(like v1.9.x) ## Code Reviews All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) for more information on using pull requests. -* 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) +* 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) * If PR is fixing any issues from [github-issues](github.com/openebs/cstor-csi/issues) then you need to mention the issue number with a link in PR description. like: _fixes https://github.com/openebs/cstor-csi/issues/56_ diff --git a/GOVERNANCE.md b/GOVERNANCE.md index da567efc2..24f514e20 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,3 +1,3 @@ This is a OpenEBS sub project and abides by the -[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md). +[OpenEBS Project Governance](https://github.com/openebs/openebs/blob/HEAD/GOVERNANCE.md). diff --git a/RELEASE.md b/RELEASE.md index 1f563c35f..eb4b804c1 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -20,7 +20,7 @@ Once all the above tests are completed, a main release tagged image is published CStor-csi is released as a container image with a versioned tag. -Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `master`. Name of the branch should follow the naming convention of `v.1.9.x` if the release is for v1.9.0. +Before creating a release, the repo owner needs to create a separate branch from the active branch, which is `develop`. Name of the branch should follow the naming convention of `v.1.9.x` if the release is for v1.9.0. Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder `changelogs/v1.9.x`, if release branch is `v1.10.x` then folder will be `changelogs/v1.10.x`. @@ -32,7 +32,7 @@ Images are published at the following location: https://quay.io/repository/openebs/cstor-csi?tab=tags https://hub.docker.com/r/openebs/cstor-csi/tags -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 `master` with the following details: +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 `cstor-csi/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 `cstor-csi/CHANGELOG.md` as part of step number 1. diff --git a/buildscripts/push b/buildscripts/push index fd7a661a5..96b024353 100755 --- a/buildscripts/push +++ b/buildscripts/push @@ -72,7 +72,7 @@ fi # set the tag CI (fixed) and build tags. BUILD_TAG="${CURRENT_BRANCH}-${BUILD_ID}" CI_TAG="${CURRENT_BRANCH}-ci" -if [ ${CURRENT_BRANCH} = "master" ]; then +if [ ${CURRENT_BRANCH} = "develop" ]; then CI_TAG="ci" fi diff --git a/ci/ci-test.sh b/ci/ci-test.sh index 4881d9be6..26103cde1 100755 --- a/ci/ci-test.sh +++ b/ci/ci-test.sh @@ -14,11 +14,11 @@ #!/usr/bin/env bash -#OPENEBS_OPERATOR=https://raw.githubusercontent.com/openebs/openebs/master/k8s/openebs-operator.yaml -NDM_OPERATOR=https://raw.githubusercontent.com/openebs/cstor-operators/master/deploy/ndm-operator.yaml -CSTOR_RBAC=https://raw.githubusercontent.com/openebs/cstor-operators/master/deploy/rbac.yaml -CSTOR_OPERATOR=https://raw.githubusercontent.com/openebs/cstor-operators/master/deploy/cstor-operator.yaml -ALL_CRD=https://raw.githubusercontent.com/openebs/cstor-operators/master/deploy/crds/all_cstor_crds.yaml +#OPENEBS_OPERATOR=https://raw.githubusercontent.com/openebs/openebs/HEAD/k8s/openebs-operator.yaml +NDM_OPERATOR=https://raw.githubusercontent.com/openebs/cstor-operators/HEAD/deploy/ndm-operator.yaml +CSTOR_RBAC=https://raw.githubusercontent.com/openebs/cstor-operators/HEAD/deploy/rbac.yaml +CSTOR_OPERATOR=https://raw.githubusercontent.com/openebs/cstor-operators/HEAD/deploy/cstor-operator.yaml +ALL_CRD=https://raw.githubusercontent.com/openebs/cstor-operators/HEAD/deploy/crds/all_cstor_crds.yaml CSI_OPERATOR="$GOPATH/src/github.com/openebs/cstor-csi/deploy/csi-operator.yaml" SNAPSHOT_CLASS="$GOPATH/src/github.com/openebs/cstor-csi/deploy/snapshot-class.yaml" diff --git a/deploy/archive/csi-operator-ubuntu-18.04.yaml b/deploy/archive/csi-operator-ubuntu-18.04.yaml index 1d45e0701..1c0da1dc9 100644 --- a/deploy/archive/csi-operator-ubuntu-18.04.yaml +++ b/deploy/archive/csi-operator-ubuntu-18.04.yaml @@ -4,11 +4,6 @@ # kernel components of iSCSI protocol. For other ubuntu flavours and # linux distros, this needs to be modified. # -# Instructions to modify: -# Ubuntu-18.04 and above: https://github.com/openebs/cstor-csi/blob/master/deploy/iscsiadm-ubuntu-18.04-and-above-deps.yaml -# SUSE Linux Enterprise Server 12: https://github.com/openebs/cstor-csi/blob/master/deploy/iscsiadm-suse-enterprise-server-12-deps.yaml -# SUSE Linux Enterprise Server 15: https://github.com/openebs/cstor-csi/blob/master/deploy/iscsiadm-suse-enterprise-server-15-deps.yaml -# # For supporting a differnet OS other than the above, # 1) Get the list of shared object files required for iscsiadm binary in that OS version. # 2) Check which files are already present in the cstor-csi-driver container present in csi node pod. diff --git a/docs/code-standard.md b/docs/code-standard.md index 6fc59b2e6..1bec3cddb 100644 --- a/docs/code-standard.md +++ b/docs/code-standard.md @@ -2,7 +2,7 @@ ## Sign your commits -We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS projects. 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 projects. 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: ```` Signed-off-by: Random J Developer diff --git a/docs/developer-setup.md b/docs/developer-setup.md index 097deb582..3145019b6 100644 --- a/docs/developer-setup.md +++ b/docs/developer-setup.md @@ -31,7 +31,7 @@ git clone https://github.com/$user/cstor-csi.git cd $GOPATH/src/github.com/openebs/cstor-csi git remote add upstream https://github.com/openebs/cstor-csi.git -# Never push to upstream master +# Never push to upstream develop git remote set-url --push upstream no_push # Confirm that your remotes make sense: @@ -70,15 +70,15 @@ Open a terminal on your local machine. Change directory to the cstor-csi fork ro $ cd $GOPATH/src/github.com/openebs/cstor-csi ``` - Check out the master branch. + Check out the develop branch. ```sh - $ git checkout master - Switched to branch 'master' - Your branch is up-to-date with 'origin/master'. + $ git checkout develop + Switched to branch 'develop' + Your branch is up-to-date with 'origin/develop'. ``` - Recall that origin/master is a branch on your remote GitHub repository. + Recall that origin/develop is a branch on your remote GitHub repository. Make sure you have the upstream remote openebs/cstor-csi by listing them. ```sh @@ -94,43 +94,43 @@ $ cd $GOPATH/src/github.com/openebs/cstor-csi ```sh $ git remote add upstream https://github.com/openebs/cstor-csi.git ``` - Fetch all the changes from the upstream master branch. + Fetch all the changes from the upstream develop branch. ```sh - $ git fetch upstream master + $ git fetch upstream develop remote: Counting objects: 141, done. remote: Compressing objects: 100% (29/29), done. remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66 Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done. Resolving deltas: 100% (79/79), done. From github.com:openebs/cstor-csi - * branch master -> FETCH_HEAD + * branch develop -> FETCH_HEAD ``` - Rebase your local master with the upstream/master. + Rebase your local develop with the upstream/develop. ```sh - $ git rebase upstream/master + $ git rebase upstream/develop First, rewinding head to replay your work on top of it... - Fast-forwarded master to upstream/master. + Fast-forwarded develop to upstream/develop. ``` - This command applies all the commits from the upstream master to your local master. + This command applies all the commits from the upstream develop to your local develop. Check the status of your local branch. ```sh $ git status - On branch master - Your branch is ahead of 'origin/master' by 12 commits. + On branch develop + Your branch is ahead of 'origin/develop' by 12 commits. (use "git push" to publish your local commits) nothing to commit, working directory clean ``` - Your local repository now has all the changes from the upstream remote. You need to push the changes to your remote fork which is origin master. + Your local repository now has all the changes from the upstream remote. You need to push the changes to your remote fork which is origin develop. - Push the rebased master to origin master. + Push the rebased develop to origin develop. ```sh - $ git push origin master + $ git push origin develop Username for 'https://github.com': $user Password for 'https://$user@github.com': Counting objects: 223, done. @@ -138,16 +138,16 @@ $ cd $GOPATH/src/github.com/openebs/cstor-csi Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done. Total 69 (delta 53), reused 47 (delta 31) To https://github.com/$user/cstor-csi.git - 8e107a9..5035fa1 master -> master + 8e107a9..5035fa1 develop -> develop ``` ### Contributing to a feature or bugfix. -Always start with creating a new branch from master to work on a new feature or bugfix. Your branch name should have the format XX-descriptive where XX is the issue number you are working on followed by some descriptive text. For example: +Always start with creating a new branch from develop to work on a new feature or bugfix. Your branch name should have the format XX-descriptive where XX is the issue number you are working on followed by some descriptive text. For example: ```sh - $ git checkout master - # Make sure the master is rebased with the latest changes as described in the previous step. + $ git checkout develop + # Make sure the develop is rebased with the latest changes as described in the previous step. $ git checkout -b 1234-fix-developer-docs Switched to a new branch '1234-fix-developer-docs' ``` @@ -160,7 +160,7 @@ Happy Hacking! ```sh # While on your myfeature branch (see above) git fetch upstream -git rebase upstream/master +git rebase upstream/develop ``` While you rebase your changes, you must resolve any conflicts that might arise and build and test your changes using the above steps.