Restore gh-pages to c25f36e

.gitignore

@@ -0,0 +1,46 @@
+# Binaries for programs and plugins
+*.exe
+*.exe~
+*.dll
+*.so
+*.dylib
+
+# Test binary, built with `go test -c`
+*.test
+
+# Output of the go coverage tool, specifically when used with LiteIDE
+*.out
+
+# Dependency directories (remove the comment below to include it)
+# vendor/
+
+# IDEs
+.vscode/*
+
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+site/node_modules
+site/.pnp
+site/.pnp.js
+
+# testing
+site/coverage
+
+# production
+site/build
+
+# misc
+site/.DS_Store
+site/.env.local
+site/.env.development.local
+site/.env.test.local
+site/.env.production.local
+
+site/npm-debug.log*
+site/yarn-debug.log*
+site/yarn-error.log*
+
+.DS_Store
+.github/.DS_Store
+

.golangci.yml

@@ -0,0 +1,150 @@
+linters-settings:
+  depguard:
+    list-type: blacklist
+    packages:
+      # logging is allowed only by logutils.Log, logrus
+      # is allowed to use only in logutils package
+      - github.com/sirupsen/logrus
+    packages-with-error-message:
+      - github.com/sirupsen/logrus: "logging is allowed only by logutils.Log"
+  dupl:
+    threshold: 100
+  exhaustive:
+    default-signifies-exhaustive: false
+  funlen:
+    lines: 100
+    statements: 50
+  gci:
+    local-prefixes: github.com/golangci/golangci-lint
+  goconst:
+    min-len: 2
+    min-occurrences: 2
+  gocritic:
+    enabled-tags:
+      - diagnostic
+      - experimental
+      - opinionated
+      - performance
+      - style
+    disabled-checks:
+      - dupImport # https://github.com/go-critic/go-critic/issues/845
+      - ifElseChain
+      - octalLiteral
+      - whyNoLint
+      - wrapperFunc
+  gocyclo:
+    min-complexity: 15
+  goimports:
+    local-prefixes: github.com/golangci/golangci-lint
+  golint:
+    min-confidence: 0
+  gomnd:
+    settings:
+      mnd:
+        # don't include the "operation" and "assign"
+        checks: argument,case,condition,return
+  gosec:
+    settings:
+      exclude: -G204
+  govet:
+    check-shadowing: false
+    settings:
+      printf:
+        funcs:
+          - (github.com/golangci/golangci-lint/pkg/logutils.Log).Infof
+          - (github.com/golangci/golangci-lint/pkg/logutils.Log).Warnf
+          - (github.com/golangci/golangci-lint/pkg/logutils.Log).Errorf
+          - (github.com/golangci/golangci-lint/pkg/logutils.Log).Fatalf
+  lll:
+    line-length: 950
+  maligned:
+    suggest-new: true
+  misspell:
+    locale: US
+  nolintlint:
+    allow-leading-space: true # don't require machine-readable nolint directives (i.e. with no leading space)
+    allow-unused: false # report any unused nolint directives
+    require-explanation: false # don't require an explanation for nolint directives
+    require-specific: false # don't require nolint directives to be specific about which linter is being skipped
+
+linters:
+  # please, do not use `enable-all`: it's deprecated and will be removed soon.
+  # inverted configuration with `enable-all` and `disable` is not scalable during updates of golangci-lint
+  disable-all: true
+  enable:
+    # todo[kushthedude]: commenting most of the checks as our code can't persist all of the changes, however we can plan further on code-quality after v1.0 release.
+    # - bodyclose
+    # - deadcode
+    - dogsled
+    - errcheck
+    # - exhaustive
+    # - funlen
+    # - goconst
+    # - gocritic
+    # - gocyclo
+    - gofmt
+    - goimports
+    - golint
+    # todo[kusthedude]: restore gosec check, once this issue is resolved https://github.com/golangci/golangci-lint/issues/177
+    # - gosec
+    # - gomnd
+    # - goprintffuncname
+    # - gosimple
+    - govet
+    # - ineffassign
+    # - interfacer
+    - lll
+    - misspell
+    # - nakedret
+    # - nolintlint
+    # - rowserrcheck
+    # - scopelint
+    - staticcheck
+    # - structcheck
+    - stylecheck
+    - typecheck
+    # - unconvert
+    # - unparam
+    # - unused
+    # - varcheck
+    - whitespace
+
+  # don't enable:
+  # - asciicheck
+  # - gochecknoglobals
+  # - gocognit
+  # - godot
+  # - godox
+  # - goerr113
+  # - maligned
+  # - nestif
+  # - prealloc
+  # - testpackage
+  # - wsl
+
+issues:
+  # Excluding configuration per-path, per-linter, per-text and per-source
+  exclude-rules:
+    - path: _test\.go
+      linters:
+        - gomnd
+
+    # https://github.com/go-critic/go-critic/issues/926
+    - linters:
+        - gocritic
+      text: "unnecessaryDefer:"
+
+run:
+  skip-dirs:
+    - test/testdata_etc
+    - internal/cache
+    - internal/renameio
+    - internal/robustio
+  timeout: 5m
+
+# golangci.com configuration
+# https://github.com/golangci/golangci/wiki/Configuration
+service:
+  golangci-lint-version: 1.23.x # use the fixed version to not introduce new linters unexpectedly
+  prepare:
+    - echo "here I can run custom commands, but no preparation needed for this repo"

CODE_OF_CONDUCT.md

@@ -0,0 +1,5 @@
+# Meshery Community Code of Conduct
+
+The Meshery project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting community@meshery.io.

CONTRIBUTING-gitflow.md

@@ -0,0 +1,95 @@
+# Working by Forking
+Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line:
+
+## Clone your fork to your local machine
+```
+git clone git@github.com:USERNAME/FORKED-PROJECT.git
+```
+Keeping Your Fork Up to Date
+While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:
+
+## Add 'upstream' repo to list of remotes
+```
+git remote add upstream https://github.com/meshery/meshery.git
+``` 
+("meshery" is used as the example repo. Be sure to reference the _actual_ repo you're contributing to e.g. "meshery-linkerd").
+
+## Verify the new remote named 'upstream'
+```
+git remote -v
+```
+Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:
+
+## Fetch from upstream remote
+```
+git fetch upstream
+```
+
+## View all branches, including those from upstream
+```
+git branch -va
+```
+Now, checkout your own master branch and merge the upstream repo's master branch:
+
+## Checkout your master branch and merge upstream
+```
+git checkout master
+git merge upstream/master
+```
+If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - see the next section, you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
+
+Now, your local master branch is up-to-date with everything modified upstream.
+
+**Create a Branch** (doing your work)
+Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
+
+To create a new branch and start working on it, peform the following flow.
+
+## Checkout the master branch - you want your new branch to come from master
+```
+git checkout master
+```
+
+## Create a new branch (give your branch its own simple informative name)
+For enhancements use `feature/your_username/issue#` or `feature/your_username/name_of_feature`
+
+For bugs use `bug/your_username/issue#` or `bug/your_username/name_of_bug`
+
+```
+git branch feature/jdoe/567
+```
+
+## Switch to your new branch
+```
+git checkout feature/jdoe/567
+```
+Now, go to town hacking away and making whatever changes you want to.
+
+## Submitting your changes (a Pull Request)
+Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.
+
+In the time that you've been working on your changes, if any commits have been made to the upstream master branch, you will need to rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
+
+## Fetch upstream master and merge with your repo's master branch
+```
+git fetch upstream
+git checkout master
+git merge upstream/master
+```
+
+## If there were any new commits, rebase your development branch
+```
+git checkout feature/jdoe/567
+git rebase master
+```
+Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
+
+## Rebase all commits on your development branch
+```
+git checkout
+git rebase -i master
+```
+This will open up a text editor where you can specify which commits to squash.
+
+## Submitting
+Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.