chore: Moving code from previous repository

.github/workflows/lint.yml

@@ -0,0 +1,35 @@
+name: Lint
+# Lint runs golangci-lint over the entire Evmos repository This workflow is
+# run on every pull request and push to main The `golangci` will pass without
+# running if no *.{go, mod, sum} files have been changed.
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+jobs:
+  golangci:
+    name: Run golangci-lint
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      # Required: setup-go, for all versions v3.0.0+ of golangci-lint
+      - uses: actions/setup-go@v3
+        with:
+          go-version: 1.18
+          check-latest: true
+      - uses: actions/checkout@v3
+      - uses: technote-space/[email protected]
+        with:
+          PATTERNS: |
+            **/**.go
+            go.mod
+            go.sum
+      - uses: golangci/[email protected]
+        with:
+          # Required: the version of golangci-lint is required and must be specified without patch version: we always use the latest patch version.
+          version: latest
+          args: --timeout 10m
+          github-token: ${{ secrets.github_token }}
+        # Check only if there are differences in the source code
+        if: "env.GIT_DIFF"

.github/workflows/test.yaml

@@ -0,0 +1,14 @@
+name: docker-compose-actions-workflow
+on: 
+  push:
+    branches-ignore: 
+      - main
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - name: Build the stack
+        run: docker-compose up -d
+      - name: Test
+        run: docker run --network container:nginx appropriate/curl -s --retry 10 --retry-connrefused http://localhost:80/HealthCheck

.gitignore

@@ -0,0 +1,2 @@
+go-backend
+dashboard-backend

.golangci.yml

@@ -0,0 +1,63 @@
+run:
+  tests: true
+  timeout: 5m
+  concurrency: 4
+
+linters:
+  enable:
+    - depguard
+    - dogsled
+    - dupl
+    - errcheck
+    - goconst
+    - gocritic
+    - gofumpt
+    - revive
+    - gosec
+    - gosimple
+    - govet
+    - ineffassign
+    # - lll TODO: enable
+    - misspell
+    - nakedret
+    - prealloc
+    - exportloopref
+    - staticcheck
+    - stylecheck
+    - typecheck
+    - unconvert
+    - unparam
+    - unused
+    - nolintlint
+    - asciicheck
+    - exportloopref
+    - gofumpt
+    - gomodguard
+
+
+
+linters-settings:
+  dogsled:
+    max-blank-identifiers: 3
+  golint:
+    min-confidence: 0
+  maligned:
+    suggest-new: true
+  misspell:
+    locale: US
+  nolintlint:
+    allow-unused: false
+    allow-leading-space: true
+    require-explanation: false
+    require-specific: false
+  gofumpt:
+    lang-version: "1.19"
+  gomodguard:
+    blocked:
+      versions:                                                         # List of blocked module version constraints
+        - https://github.com/etcd-io/etcd:                              # Blocked module with version constraint
+            version: ">= 3.4.10 || ~3.3.23"                             # Version constraint, see https://github.com/Masterminds/semver#basic-comparisons
+            reason: "CVE-2020-15114; CVE-2020-15136; CVE-2020-15115"    # Reason why the version constraint exists. (Optional)
+        - https://github.com/dgrijalva/jwt-go:                          # Blocked module with version constraint
+            version: ">= 4.0.0-preview1"                                # Version constraint, see https://github.com/Masterminds/semver#basic-comparisons
+            reason: "CVE-2020-26160"                                    # Reason why the version constraint exists. (Optional)

CHANGELOG.md

@@ -0,0 +1,41 @@
+<!--
+Guiding Principles:
+
+Changelogs are for humans, not machines.
+There should be an entry for every single version.
+The same types of changes should be grouped.
+Versions and sections should be linkable.
+The latest version comes first.
+The release date of each version is displayed.
+Mention whether you follow Semantic Versioning.
+
+Usage:
+
+Change log entries are to be added to the Unreleased section under the
+appropriate stanza (see below). Each entry should ideally include a tag and
+the Github issue reference in the following format:
+
+* (<tag>) \#<issue-number> message
+
+The issue numbers will later be link-ified during the release process so you do
+not have to worry about including a link manually, but you can if you wish.
+
+Types of changes (Stanzas):
+
+"Features" for new features.
+"Improvements" for changes in existing functionality.
+"Deprecated" for soon-to-be removed features.
+"Bug Fixes" for any bug fixes.
+"Client Breaking" for breaking CLI commands and REST routes used by end-users.
+"API Breaking" for breaking exported APIs used by developers building on SDK.
+
+Ref: https://keepachangelog.com/en/1.0.0/
+-->
+
+# Changelog
+
+## Unreleased
+
+### Improvements
+
+- (ci) [#107](https://github.com/evmos/backend/pull/107) Add golangci linter.

CONTRIBUTING.md

@@ -0,0 +1,112 @@
+# Evmos Contributor Guidelines
+
+<!-- markdown-link-check-disable -->
+
+- [General Procedure](#general_procedure)
+- [Testing](#testing)
+- [Updating Documentation](#updating_doc)
+- [Commit messages](#commit_messages)
+  - [PR Targeting](#pr_targeting)
+  - [Pull Requests](#pull_requests)
+  - [Process for reviewing PRs](#reviewing_prs)
+  <!-- markdown-link-check-enable -->
+
+## <span id="general_procedure">General Procedure</span>
+
+Thank you for considering making contributions to Evmos and related repositories!
+
+Contributing to this repo can mean many things such as participating in discussion or proposing code changes.
+To ensure a smooth workflow for all contributors,
+the following general procedure for contributing has been established:
+
+1. Either [open](https://github.com/evmos/apps/issues/new/choose)
+   or [find](https://github.com/evmos/apps/issues) an issue you have identified and would like to contribute to
+   resolving.
+2. Participate in thoughtful discussion on that issue.
+3. If you would like to contribute:
+   1. If the issue is a proposal, ensure that the proposal has been accepted by the Evmos team.
+   2. Ensure that nobody else has already begun working on the same issue. If someone already has, please make sure to
+      contact the individual to collaborate.
+   3. If nobody has been assigned the issue and you would like to work on it,
+      make a comment on the issue to inform the
+      community of your intentions to begin work.
+      Ideally, wait for confirmation that no one has started it.
+      However, if you are eager and do not get a prompt response, feel free to dive on in!
+   4. Follow standard Github best practices:
+      1. Fork the repo
+      2. Branch from the HEAD of `development`(For core developers working within the evmos repo, to ensure a
+         clear ownership of branches, branches must be named with the convention `{moniker}/{issue#}-branch-name`).
+      3. Make commits
+      4. Submit a PR to `development`
+   5. Be sure to submit the PR in `Draft` mode.
+      Submit your PR early, even if it's incomplete as this indicates to the community you're working on something
+      and allows them to provide comments early in the development process.
+   6. When the code is complete it can be marked `Ready for Review`.
+   7. Be sure to include a relevant change log entry in the `Unreleased` section of `CHANGELOG.md`
+      (see file for log format).
+   8. Please make sure to run `make format` before every commit -
+      the easiest way to do this is having your editor run it for you upon saving a file.
+      Additionally, please ensure that your code is lint compliant by running `make lint`.
+      There are CI tests built into the Evmos repository
+      and all PR’s will require that these tests pass
+      before they can be merged.
+
+**Note**: for very small or blatantly obvious problems (such as typos),
+it is not required to open an issue to submit a PR.
+For more complex problems/features, if a PR is opened
+before an adequate design discussion has taken place in a GitHub issue,
+that PR runs a high likelihood of being rejected.
+
+Looking for a good place to start contributing?
+Check out our [good first issues](https://github.com/evmos/apps/issues?q=label%3A%22good+first+issue%22).
+
+## <span id="testing">Testing</span>
+
+Evmos uses [GitHub Actions](https://github.com/features/actions) for automated testing.
+
+## <span id="updating_doc">Updating Documentation</span>
+
+If you open a PR on the Evmos repo, it is mandatory to update the relevant documentation in `/docs`. Please refer to
+the docs subdirectory and make changes accordingly. Prior to approval, the Code owners/approvers may request some
+updates to specific docs.
+
+## <span id="commit_messages">Commit messages</span>
+
+Commit messages should be written in a short, descriptive manner
+and be prefixed with tags for the change type and scope (if possible)
+according to the [semantic commit](https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716) scheme.
+
+For example, a new change to the `bank` module might have the following message:
+`feat(bank): add balance query cli command`
+
+### <span id="pr_targeting">PR Targeting</span>
+
+Ensure that you base and target your PR on the `development` branch.
+
+All feature additions should be targeted against `development`.
+Bug fixes for an outstanding release candidate should be
+targeted against the release candidate branch.
+
+### <span id="pull_requests">Pull Requests</span>
+
+To accommodate the review process, we suggest that PRs are categorically broken up. Ideally each PR addresses only a
+single issue. Additionally, as much as possible code refactoring and cleanup should be submitted as separate PRs from
+bug fixes/feature-additions.
+
+### <span id="reviewing_prs">Process for reviewing PRs</span>
+
+All PRs require two Reviews before merge. When reviewing PRs, please use the following review explanations:
+
+1. `LGTM` without an explicit approval means that the changes look good,
+   but you haven't pulled down the code, ran tests locally and thoroughly reviewed it.
+2. `Approval` through the GH UI means that you understand the code,
+   documentation/spec is updated in the right places,
+   you have pulled down and tested the code locally.
+   In addition:
+   - You must think through whether any added code could be partially combined (DRYed) with existing code.
+   - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes.
+   - Naming convention must be consistent with the rest of the codebase.
+   - Code must live in a reasonable location, considering dependency structures
+     (e.g. not importing testing modules in production code, or including example code modules in production code).
+   - If you approve of the PR, you are responsible for fixing any of the issues mentioned here.
+3. If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review.

LICENSE

@@ -0,0 +1,64 @@
+Evmos Non-Commercial License
+
+Version 1.0 dated April 21th, 2023
+
+This license contains the terms and conditions under which Tharsis Labs Ltd.
+(“Company”) makes available its Software. Your use of the Software is subject to
+these terms and conditions.
+
+Company grants you (“Licensee”) a license to use, modify, and redistribute the
+Software, but only (a) for Non-Commercial Use, or (b) for Commercial Use only on
+the Designated Blockchains.
+
+If Licensee makes available a copy of the Software to any third party, the
+Software must be subject to the terms of this license only, and Licensee must
+provide a copy of this license to that third party. All restrictions and
+conditions of this license apply to the Software or any portion or modification
+of the Software made under this license.
+
+These terms do not allow Licensee to sublicense or transfer any of Licensee’s
+rights to anyone else. These terms do not imply any other licenses not expressly
+granted in this license.
+
+If Licensee violates any of these terms or uses the Software in a way not
+authorized under this license, the license granted to Licensee ends immediately.
+If Licensee makes, or authorizes any other person to make, any written claim
+that the Software, or any other Evmos Product (see below), infringes or
+contributes to the infringement of any patent, all rights granted to Licensee
+under this license end immediately.
+
+As far as the law allows, the Software is provided AS IS, without any warranty
+or condition, and Company will not be liable to Licensee for any damages arising
+out of these terms or the use or nature of the Software, under any kind of legal
+claim.
+
+Terms in this license are used as follows:
+
+“Software” means the blockchain software developed by the Company, which is the
+implementation of the Evmos blockchains available at
+“https://github.com/evmos/evmos” and the Evmos applications at
+“https://github.com/evmos/backend” and “https://github.com/evmos/apps” as may be
+updated from time to time.
+
+"Designated Blockchains" refer to the version of the digital blockchain ledger
+that, at any given time, is recognized as canonical in accordance with the
+blockchain consensus.
+
+A “Evmos Product” is any product or service offered by the Company or its
+affiliates.
+
+“Non-Commercial Use” means academic, scientific, or research and development
+use, or evaluating the Software (such as. through auditing), but does not
+include the creation of a publicly available blockchain, precompiled smart
+contracts, or other distributed-ledger technology systems that facilitate any
+transaction of economic value.
+
+“Commercial Use” is any use that is not a Non-Commercial Use.
+
+To “use” means any use, modification, distribution or other exploitation of the
+Software or any part of it.
+
+---
+
+For more information, please refer to the official ENCL-1.0 FAQ
+(https://github.com/evmos/backend/blob/main/LICENSE_FAQ.md).