chore(build): update default/build branch from replication to develop (#359)

* updating branch reference from replication to develop

- CONTRIBUTING.md
- README.md
- RELEASE.md
- developer-setup.md
- GOVERNANCE.md
- fetch-libcstor-branch.sh
- code-standard.md

* updating build branch to 'develop' in github workflow
* add ghcr as an container repository to host container images

Signed-off-by: mittachaitu <[email protected]>

Author: sai chaithanya

.github/workflows/build.yml

@@ -17,7 +17,7 @@ on:
   create:
   push:
     branches:
-    - replication
+    - develop
     - 'v*'
     paths-ignore:
     - 'docs/**'
@@ -71,7 +71,7 @@ jobs:
         run: |
           BRANCH="${GITHUB_REF##*/}"
           CI_TAG=${BRANCH#v}-ci
-          if [ ${BRANCH} = "replication" ]; then
+          if [ ${BRANCH} = "develop" ]; then
             CI_TAG="ci"
           fi
           echo "TAG=${CI_TAG}" >> $GITHUB_ENV
@@ -90,6 +90,7 @@ jobs:
           images: |
             ${{ env.IMAGE_ORG }}/cstor-istgt
             quay.io/${{ env.IMAGE_ORG }}/cstor-istgt
+            ghcr.io/${{ env.IMAGE_ORG }}/cstor-istgt
           tag-latest: false
           tag-custom-only: true
           tag-custom: |
@@ -124,6 +125,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:

.github/workflows/pull_request.yml

@@ -21,8 +21,8 @@ on:
       - 'changelogs/**'
       - '*.md'
     branches:
-      # on pull requests to master and release branches
-      - replication
+      # on pull requests to develop and release branches
+      - develop
       - 'v*'
 
 jobs:

.github/workflows/release.yml

@@ -52,6 +52,7 @@ jobs:
           images: |
             ${{ env.IMAGE_ORG }}/cstor-istgt
             quay.io/${{ env.IMAGE_ORG }}/cstor-istgt
+            ghcr.io/${{ env.IMAGE_ORG }}/cstor-istgt
           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:

CONTRIBUTING.md

@@ -47,7 +47,7 @@ istgt is an Apache 2.0 Licensed project and all your commits should be signed wi
 * Find an issue to work on or create a new issue. The issues are maintained at [openebs/istgt](https://github.com/openebs/istgt/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 from replication branch).
+* Create a branch from where you want to base your work (usually from develop branch).
 * Make your changes. If you are working on code contributions, please see [Setting up the Development Environment](#setting-up-your-development-environment).
 * 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](code-standard.md).
@@ -56,7 +56,7 @@ istgt is an Apache 2.0 Licensed project and all your commits should be signed wi
 * Submit a pull request to the original repository. See [Pull Request checklist](#pull-request-checklist).
 
 ## Pull Request Checklist
-* Rebase to the current replication 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.

GOVERNANCE.md

@@ -1,2 +1,2 @@
 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/main/GOVERNANCE.md).

README.md

@@ -1,16 +1,16 @@
-[![Build Status](https://travis-ci.org/openebs/istgt.svg?branch=replication)](https://travis-ci.org/openebs/istgt)
+[![Build Status](https://github.com/openebs/istgt/actions/workflows/build.yml/badge.svg)](https://github.com/openebs/istgt/actions/workflows/build.yml)
 [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fistgt.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fistgt?ref=badge_shield)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/2738/badge)](https://bestpractices.coreinfrastructure.org/projects/2738)
 [![Slack](https://img.shields.io/badge/chat!!!-slack-ff1493.svg?style=flat-square)](https://kubernetes.slack.com/messages/openebs)
 
 ### Instructions to check cstyle
 ```sh
-Checkout replication branch
+Checkout develop branch
 Do ./cstyle.pl <filename with path>
 ```
 ### Building
 ```bash
-git checkout replication
+git checkout develop
 sudo apt-get install libssl-dev docker.io
 sudo apt-get install autoconf
 ./autogen.sh

RELEASE.md

@@ -20,7 +20,7 @@ Once all the above tests are completed, a main release tagged image is published
 
 istgt is released as container image with versioned tag.
 
-Before creating a release, repo owner needs to create a separate branch from the active branch, which is `replication`. Name of the branch should follow the naming convention of `v.1.9.x`, if release is for v1.9.0.
+Before creating a release, 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 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 following location:
 https://quay.io/repository/openebs/cstor-istgt?tab=tags
 https://hub.docker.com/r/openebs/cstor-istgt/tags
 
-Once a release is created, update the release description with the change log mentioned in `changelog/v1.9.x`. Once the change logs are updated in release, repo owner needs to create a PR to `replication` with the following details:
+Once a release is created, update the release description with the change log mentioned in `changelog/v1.9.x`. Once the change logs are updated in release, repo owner needs to create a PR to `develop` with the following details:
 1. update the changelog from `changelog/v1.9.x` to `istgt/CHANGELOG.md`
 2. If release is not a RC tag then PR should include the changes to remove `changelog/v1.9.x` folder.
 3. If release is a RC tag then PR should include the changes to remove the changelog from `changelog/v1.9.x` which are already mentioned in `istgt/CHANGELOG.md` as part of step number 1.

code-standard.md

@@ -2,7 +2,7 @@
 
 ## 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/main/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 <[email protected]>

developer-setup.md

@@ -35,7 +35,7 @@ git clone https://github.com/$user/istgt.git
 cd istgt
 git remote add upstream https://github.com/openebs/istgt.git
 
-# Never push to upstream replication
+# Never push to upstream develop
 git remote set-url --push upstream no_push
 
 # Confirm that your remotes make sense
@@ -44,7 +44,7 @@ git remote -v
 
 ### Instructions to check cstyle
 ```
-Checkout replication branch
+Checkout develop branch
 Do ./cstyle.pl <filename with path>
 ```
 
@@ -80,15 +80,15 @@ Open a terminal on your local host. Change directory to the istgt fork root.
 $ cd <path_to_fork_repo>
 ```
 
- Checkout the replication branch.
+ Checkout the develop branch.
 
  ```sh
- $ git checkout replication
- Switched to branch 'replication'
- Your branch is up-to-date with 'origin/replication'.
+ $ git checkout develop
+ Switched to branch 'develop'
+ Your branch is up-to-date with 'origin/develop'.
  ```
 
- Recall that origin/replication 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/istgt by listing them.
 
  ```sh
@@ -104,22 +104,22 @@ $ cd <path_to_fork_repo>
  ```sh
  $ git remote add upstream https://github.com/openebs/istgt.git
  ```
- Fetch all the changes from the upstream replication branch.
+ Fetch all the changes from the upstream develop branch.
 
  ```sh
- $ git fetch upstream replication
+ $ git fetch upstream develop
  From https://github.com/openebs/istgt
- * branch            replication -> FETCH_HEAD
+ * branch            develop -> FETCH_HEAD
  ```
 
- Rebase your local replication branch with the upstream/replication.
+ Rebase your local develop branch with the upstream/develop.
 
  ```sh
- $ git rebase upstream/replication
+ $ git rebase upstream/develop
  First, rewinding head to replay your work on top of it...
- Fast-forwarded replication to upstream/replication.
+ Fast-forwarded develop to upstream/develop.
  ```
- This command applies all the commits from the upstream replication to your local development branch.
+ This command applies all the commits from the upstream develop to your local development branch.
 
  Check the status of your local branch.
 
@@ -128,29 +128,29 @@ $ cd <path_to_fork_repo>
  On branch develop
  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 own remote fork which is origin replication.
+ Your local repository now has all the changes from the upstream remote. You need to push the changes to your own remote fork which is origin develop.
 
- Push the rebased replication to origin replication.
+ Push the rebased develop to origin develop.
 
  ```sh
- $ git push origin replication
+ $ git push origin develop
  Username for 'https://github.com': $user
  Password for 'https://[email protected]':
  Counting objects: 223, done.
  Compressing objects: 100% (38/38), done.
  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/istgt.git
- 8e107a9..5035fa1  replication -> replication
+ 8e107a9..5035fa1  develop -> develop
  ```
 
 ### Contributing to a feature or bugfix.
 
-Always start with creating a new branch from replication 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 replication
- # Make sure the replication is rebased with the latest changes as described in previous step.
+ $ git checkout develop
+ # Make sure the develop is rebased with the latest changes as described in previous step.
  $ git checkout -b 1234-fix-developer-docs
  Switched to a new branch '1234-fix-developer-docs'
  ```
@@ -163,7 +163,7 @@ Happy Hacking!
 ```sh
 # While on your myfeature branch (see above)
 git fetch upstream
-git rebase upstream/replication
+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.

fetch-libcstor-branch.sh

@@ -37,8 +37,8 @@ set -e
 #For the moment, we will go with making sure the correct
 # branch name is provided as part of the release process.
 if [ -z ${TRAVIS_BRANCH} ] ||
-    [ ${TRAVIS_BRANCH} == "replication" ]; then
-    LIBCSTOR_BUILD_BRANCH="master"
+    [ ${TRAVIS_BRANCH} == "develop" ]; then
+    LIBCSTOR_BUILD_BRANCH="develop"
 else
     LIBCSTOR_BUILD_BRANCH=${TRAVIS_BRANCH}
 fi