diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 838b78e..fd9e8cf 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' @@ -102,7 +102,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 @@ -116,6 +116,7 @@ jobs: images: | ${{ env.IMAGE_ORG }}/velero-plugin quay.io/${{ env.IMAGE_ORG }}/velero-plugin + ghcr.io/${{ env.IMAGE_ORG }}/velero-plugin tag-latest: false tag-custom-only: true tag-custom: | @@ -150,6 +151,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 06cd972..d1666ce 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' diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 39e32ed..a2f9290 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -52,6 +52,7 @@ jobs: images: | ${{ env.IMAGE_ORG }}/velero-plugin quay.io/${{ env.IMAGE_ORG }}/velero-plugin + ghcr.io/${{ env.IMAGE_ORG }}/velero-plugin 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/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index a3ee6a8..d61fe3b 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,3 +1,3 @@ ## Community Code of Conduct -This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). +This project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/HEAD/code-of-conduct.md). diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2938ada..1335e90 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,7 +8,7 @@ You can contribute to velero-plugin by filling an issue at [openebs/velero-plugi * 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 @@ -58,7 +58,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/velero-plugin](https://github.com/openebs/velero-plugin/issues). You can pick up from a list of [good-first-issues](https://github.com/openebs/velero-plugin/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](code-standard.md). * Verify that your changes pass `make lint` or `make lint-docker` (docker version of `make lint`) @@ -67,7 +67,7 @@ For setting up a development environment on your local machine, see the detailed ## 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 @@ -97,13 +97,13 @@ 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/velero-plugin/issues) then you need to mention the issue number with a link in PR description. like: _fixes _ diff --git a/GOVERNANCE.md b/GOVERNANCE.md index bd45a89..4aa9ce0 100644 --- a/GOVERNANCE.md +++ b/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/HEAD/GOVERNANCE.md). diff --git a/README.md b/README.md index d5875ae..90793bb 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ OpenEBS velero-plugin. [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fvelero-plugin.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fvelero-plugin?ref=badge_shield) [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3900/badge)](https://bestpractices.coreinfrastructure.org/projects/3900) [![Releases](https://img.shields.io/github/v/release/openebs/velero-plugin.svg?include_prereleases&style=flat-square)](https://github.com/openebs/velero-plugin/releases) -[![LICENSE](https://img.shields.io/github/license/openebs/velero-plugin.svg?style=flat-square)](https://github.com/openebs/velero-plugin/blob/master/LICENSE) +[![LICENSE](https://img.shields.io/github/license/openebs/velero-plugin.svg?style=flat-square)](https://github.com/openebs/velero-plugin/blob/HEAD/LICENSE) ## Table of Contents - [Compatibility matrix](#compatibility-matrix) @@ -55,7 +55,7 @@ _OpenEBS version **< 0.9** is not supported for velero-plugin._ _Velero-plugin version **< 1.11.0** is not supported for cstor v1 volumes._ -_If you want to use plugin image from development branch(`master`), use **ci** tag._ +_If you want to use plugin image from development branch(`develop`), use **ci** tag._ Multiarch (amd64/arm64) plugin images are available at [Docker Hub](https://hub.docker.com/r/openebs/velero-plugin/tags). @@ -326,7 +326,7 @@ NAME STATUS CREATED SCHEDULE BACKUP T newschedule Enabled 2019-05-13 15:15:39 +0530 IST */5 * * * * 720h0m0s 2m ago ``` -During the first backup iteration of a schedule, full data of the volume will be backed up. For later backup iterations of a schedule, only modified or new data from the previous iteration will be backed up. Since Velero backup comes with [retain policy](https://velero.io/docs/master/how-velero-works/#set-a-backup-to-expire), you may need to update the retain policy using argument `--ttl` while creating a schedule. Since scheduled backups are incremental backup, if first backup(or base backup) gets expired then you won't be able to restore from that schedule. +During the first backup iteration of a schedule, full data of the volume will be backed up. For later backup iterations of a schedule, only modified or new data from the previous iteration will be backed up. Since Velero backup comes with [retain policy](https://velero.io/docs/main/how-velero-works/#set-a-backup-to-expire), you may need to update the retain policy using argument `--ttl` while creating a schedule. Since scheduled backups are incremental backup, if first backup(or base backup) gets expired then you won't be able to restore from that schedule. *Note:* - _If backup name ends with "-20190513104034" format then it is considered as part of scheduled backup_ diff --git a/RELEASE.md b/RELEASE.md index d73d1e9..94860bd 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 velero-plugin 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 folder `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`. @@ -34,12 +34,12 @@ https://hub.docker.com/r/openebs/velero-plugin/tags ``` -Once a release is created, update the release description with the changelog mentioned in folder `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 folder `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 folder `changelog/v1.9.x` to file `velero-plugin/CHANGELOG-v1.9.md` 2. If a release is an RC tag then PR should include the changes to remove the changelog from folder`changelog/v1.9.x` which are already mentioned in `velero-plugin/CHANGELOG-v1.9.md` as part of step number 1. 3. If a release is not an RC tag then - PR should include the changes to remove files from `changelog/v1.9.x` folder. - - PR should update the root [CHANGELOG file](https://github.com/openebs/velero-plugin/blob/master/CHANGELOG.md) with contents of file `velero-plugin/CHANGELOG-v1.9.md` + - PR should update the root [CHANGELOG file](https://github.com/openebs/velero-plugin/blob/HEAD/CHANGELOG.md) with contents of file `velero-plugin/CHANGELOG-v1.9.md` Format of the `velero-plugin/CHANGELOG-v1.9.md` file must be as below: ``` diff --git a/code-standard.md b/code-standard.md index f528975..2688cf4 100644 --- a/code-standard.md +++ b/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/developer-setup.md b/developer-setup.md index 95a8e97..5f9199e 100644 --- a/developer-setup.md +++ b/developer-setup.md @@ -5,7 +5,7 @@ * You have Go 1.14 installed on your local development machine. * You have Docker installed on your local development machine. Docker is required for building velero-plugin container images and to push them into a Kubernetes cluster for testing. -* You have `kubectl` installed. For running integration tests, you will require an existing single node cluster with [openebs](https://blog.openebs.io/how-to-install-openebs-with-kubernetes-using-minikube-2ed488dff1c2) and [velero](https://velero.io/docs/master/basic-install/) installed. Don't worry if you don't have access to the Kubernetes cluster, raising a PR with the velero-plugin repository will run integration tests for your changes against a Minikube cluster. +* You have `kubectl` installed. For running integration tests, you will require an existing single node cluster with [openebs](https://blog.openebs.io/how-to-install-openebs-with-kubernetes-using-minikube-2ed488dff1c2) and [velero](https://velero.io/docs/main/basic-install/) installed. Don't worry if you don't have access to the Kubernetes cluster, raising a PR with the velero-plugin repository will run integration tests for your changes against a Minikube cluster. ## Initial Setup @@ -31,7 +31,7 @@ git clone https://github.com/$user/velero-plugin.git cd $GOPATH/src/github.com/openebs/velero-plugin git remote add upstream https://github.com/openebs/velero-plugin.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: @@ -74,15 +74,15 @@ Open a terminal on your local machine. Change directory to the velero-plugin for cd $GOPATH/src/github.com/openebs/velero-plugin ``` - 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/velero-plugin by listing them. ```sh @@ -99,45 +99,45 @@ cd $GOPATH/src/github.com/openebs/velero-plugin git remote add upstream https://github.com/openebs/velero-plugin.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/velero-plugin - * 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. @@ -145,16 +145,16 @@ cd $GOPATH/src/github.com/openebs/velero-plugin 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/velero-plugin.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' ``` @@ -168,7 +168,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. diff --git a/pkg/cstor/cstor.go b/pkg/cstor/cstor.go index e34eb81..e9dcd81 100644 --- a/pkg/cstor/cstor.go +++ b/pkg/cstor/cstor.go @@ -308,7 +308,7 @@ func (p *Plugin) Init(config map[string]string) error { } // SetOpenEBSAPIClient sets openebs client from openebs/apis -// Ref: https://github.com/openebs/api/tree/master/pkg/apis +// Ref: https://github.com/openebs/api/tree/HEAD/pkg/apis func (p *Plugin) SetOpenEBSAPIClient(c *rest.Config) error { OpenEBSAPIClient, err := openebsapis.NewForConfig(c) if err != nil {