chore(release): 1.0.0-beta.1

Co-authored-by: 0xng <[email protected]>
Co-authored-by: wei3erHase <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,31 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ""
+labels: ""
+assignees: ""
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**Reproduction steps**
+
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**System Specs:**
+
+- OS:
+- Package Version (or commit hash):
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,19 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ""
+labels: ""
+assignees: ""
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,6 @@
+**Description**
+A clear and concise description of the features you're adding in this pull request.
+
+**Metadata**
+
+- Fixes #[Link to Issue]

.github/workflows/canary.yml

@@ -0,0 +1,21 @@
+name: Canary release
+
+on: workflow_dispatch
+
+jobs:
+  canary-publish:
+    name: Publish Packages (canary)
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+        with:
+          node-version: "14.x"
+          registry-url: "https://registry.npmjs.org"
+      - run: yarn
+      - run: yarn build
+      - run: yarn version --new-version "0.0.0-${GITHUB_SHA::8}" --no-git-tag-version
+      - run: npm publish --access public --tag canary
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

.github/workflows/lint.yml

@@ -0,0 +1,47 @@
+name: Lint
+
+on: [push]
+
+jobs:
+  files:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out github repository
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 1
+
+      - name: Cache node modules
+        uses: actions/cache@v2
+        env:
+          cache-name: cache-node-modules
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
+          restore-keys: |
+            ${{ runner.os }}-build-${{ env.cache-name }}-
+            ${{ runner.os }}-build-
+            ${{ runner.os }}-
+      - name: Install node
+        uses: actions/setup-node@v1
+        with:
+          node-version: "12.x"
+
+      - name: Install dependencies
+        run: yarn --frozen-lockfile
+
+      - name: Run linter
+        run: yarn run lint:check
+
+  commits:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out github repository
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 0
+
+      - name: Run commitlint
+        uses: wagoid/commitlint-github-action@v2

.github/workflows/release.yml

@@ -0,0 +1,53 @@
+name: Build, tag, and publish a release
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  tag:
+    name: Create tag for new version
+    runs-on: ubuntu-latest
+    outputs:
+      tag_name: ${{ steps.create_new_tag.outputs.tag }}
+    steps:
+      - uses: actions/checkout@v2
+        with:
+          fetch-depth: 2
+      - uses: salsify/action-detect-and-tag-new-version@v2
+        id: create_new_tag
+
+  release:
+    name: Create release
+    runs-on: ubuntu-latest
+    needs: tag
+    if: needs.tag.outputs.tag_name
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/create-release@v1
+        id: create_release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          tag_name: ${{ needs.tag.outputs.tag_name }}
+          release_name: ${{ needs.tag.outputs.tag_name }}
+          draft: false
+          prerelease: false
+
+  publish:
+    name: Build and publish
+    runs-on: ubuntu-latest
+    needs: tag
+    if: needs.tag.outputs.tag_name
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+        with:
+          node-version: "14.x"
+          registry-url: "https://registry.npmjs.org"
+      - run: yarn
+      - run: yarn build
+      - run: npm publish --access public
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

.gitignore

@@ -0,0 +1,7 @@
+# General
+node_modules
+.DS_STORE
+yarn-error.log
+dist
+build
+_build

.husky/.gitignore

@@ -0,0 +1 @@
+_

.husky/commit-msg

@@ -0,0 +1,4 @@
+#!/bin/sh
+. "$(dirname "$0")/_/husky.sh"
+
+npx --no-install commitlint --edit $1

.husky/pre-commit

@@ -0,0 +1,4 @@
+#!/bin/sh
+. "$(dirname "$0")/_/husky.sh"
+
+npm run lint:fix

.prettierignore

@@ -0,0 +1,31 @@
+# General
+.prettierignore
+.solhintignore
+.husky
+.gitignore
+.gitattributes
+.env.example
+.env
+*.code-workspace
+.DS_STORE
+LICENSE
+dist
+CHANGELOG.md
+
+# Hardhat
+artifacts
+cache
+typechained
+
+# JS
+node_modules
+package-lock.json
+yarn.lock
+yarn-error.log
+
+# Solidity
+contracts/mock
+
+# Docs
+docs
+README.*

.prettierrc

@@ -0,0 +1,32 @@
+{
+  "overrides": [
+    {
+      "files": "**.sol",
+      "options": {
+        "printWidth": 145,
+        "tabWidth": 2,
+        "useTabs": false,
+        "singleQuote": true,
+        "bracketSpacing": false
+      }
+    },
+    {
+      "files": ["**.ts", "**.js"],
+      "options": {
+        "printWidth": 145,
+        "tabWidth": 2,
+        "semi": true,
+        "singleQuote": true,
+        "useTabs": false,
+        "endOfLine": "auto"
+      }
+    },
+    {
+      "files": "**.json",
+      "options": {
+        "tabWidth": 2,
+        "printWidth": 200
+      }
+    }
+  ]
+}

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+  "restructuredtext.confPath": "${workspaceFolder}\\docs\\source"
+}

LICENSE

@@ -0,0 +1,22 @@
+(The MIT License)
+
+Copyright 2021 Keep3r Network
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

README.md

@@ -0,0 +1,94 @@
+# Keep3r CLI Sample Jobs
+
+`@keep3r-network/cli-sample-jobs` aims to provide keepers using `@keep3r-network/cli` out-of-the-box jobs they can run immediately, as well as examples for job owners to follow if they wish to create scripts of their own jobs in order to add extra incentives for keepers using the CLI to run theirs.
+
+
+## Adding a Job
+
+For a detailed breakdown of how to successfully write a Keep3r CLI Job script, please refer to the **Creating a Keep3r CLI compatible job** section.
+
+If a job owner has written a script to have keepers using Keep3r CLI immediately run his job, he will have to publish this script as a separate npm package for keepers to install and run. 
+
+We recommend job owners to add their packages in a specific section of their documentation where keepers can easily find it.
+
+We have chosen this method to reduce the possibility of people uploading malicious packages disguised as jobs and distracted keepers installing them. We urge keepers running Keep3r CLI to be careful with the packages they install, and to only download jobs from trusted sources.
+
+## Testnet Jobs
+
+This repository comes with two jobs deployed to goerli that serve as a safe and easy way to test whether users running Keep3r CLI have setup their keepers correctly. These jobs are:
+
+- [Job A](https://github.com/keep3r-network/cli-sample-jobs/blob/main/src/goerli/job-a/README.md)
+- [Job A Stealth](https://github.com/keep3r-network/cli-sample-jobs/blob/main/src/goerli/job-a-stealth/README.md)
+
+## Mainnet Jobs
+
+These are real jobs keepers can run if they meet the requirements specified by the protocols. They also serve as a great example of how to write scripts for more complex jobs:
+
+- [Mean Finance](https://github.com/keep3r-network/cli-sample-jobs/blob/main/src/mainnet/dca/README.md)
+- [Yearn Harvest V2](https://github.com/keep3r-network/cli-sample-jobs/blob/main/src/mainnet/harvest-v2/README.md)
+- [Yearn Tend V2](https://github.com/keep3r-network/cli-sample-jobs/blob/main/src/mainnet/tend-v2/README.md)
+- [Yearn Tend V2 (Beta)](https://github.com/keep3r-network/cli-sample-jobs/blob/main/src/mainnet/tend-v2-2/README.md)
+
+## Job Paths
+
+To choose what jobs to run, you will need to add their paths to your `.config.json` file. You can find each job path in their respective docs.
+
+## Creating a Keep3r CLI compatible job
+
+A Keep3r CLI compatible job is as easy as it gets. You will only need to create two files:
+
+- `metadata.json`: Super simple `.json` file containing the name of the job. This is an example of how it would look like if your job was called `My First Job`.
+
+    ```bash
+    {
+      "name": "DCA"
+    }
+    ```
+
+    Right now this file seems unimportant, but in future versions it will be used to add extra information about each specific job. An example of this, would be the tokens the job uses to pay the keepers—right now we assume they pay in KP3R or ETH—which will help the Keep3r-CLI properly calculate the profitability of the transaction. In the current version, the name is used to create an id for each job, which will help the Keep3r-CLI know which job is currently in progress to avoid rerunning it unnecessarily. 
+
+- `job.ts`: This file will contain the logic of the job script, and therefore it will be the file the Keep3r-CLI runs when it intends to work your job. Writing the logic in this file can sound like a daunting task at first, but we have built everything so that there's a lot of shared logic between scripts, which makes creating a script for your job a simple task. 
+After going through the examples you will find that all the jobs follow a similar pattern to this one:
+    - Declare a variable that contains the address of your job.
+    - Create an async function called `getWorkableTxs` which will take `args` as arguments. This function will contain all the important logic to create what we call **workable groups** and send them along with an id to the Keep3r-CLI.
+    A workable group is an array that contains objects that have:
+        - The target block at which to perform a transaction.
+        - An array containing the populated transactions to be performed
+        - An id to identify each array in the workable group, so it's easier for keepers to read the logs.
+
+        For example, let's say `ExampleJob` needs a keeper to call the `work` function and let's say the keeper establishes `100` as the target block. When a keeper executes `getWorkableTxs`, this function will output the following working group:
+
+        ```bash
+        workableGroup = [{
+        	targetBlock: 100,
+        	txs: [populated tx data to call work],
+        	logId: some randomly generated id
+        }]
+        ```
+
+        This working group will then be passed to the Keep3r-CLI `job-wrapper.ts` file, for additional checks before sending the transactions to flashbots.
+        **All of the following points will be different points of logic inside `getWorkableTxs`**
+
+    - Create a `correlationId`, which will be used to track if the current job being executed to avoid rerunning it unnecessarily.
+    - Create an if check that checks, using the `correlationId`, whether that job should be rerun in a block or not. For example: the keeper runs your job at block `100`, but specifies `105` as its target block. The `correlationId` and this additional check will prevent all the logic to check whether the job is workable or not from being rerun in the blocks `101, 102, 103, 104`, where it's not necessary.
+    - Create a variable `logMetadata` containing all the relevant information you would like the keeper to see in their logs. We recommend creating an object containing the name of your job, the current block, and a logId to help identify each job.
+    - Create a `logConsole` variable that calls the `prelog` utility function passing in the `logMetadata` as an argument. This is simply used to log better logs. It appends all the information established in `logMetadata` to each log that uses `logConsole` instead of `console.log`
+    - Create a variable containing your job's contract. This will be used to populate the transactions the keeper will end up running.
+    - Create a try catch finally statement.
+    - The try statement will call the `work` function to check if, in the current block, that job can be worked or if it's on cooldown. If it is workable, it adds a log and then creates a `workableGroup` variable initialized to an empty array.
+    Things get interesting after this. Because we know the job is workable, we can now populate the transactions we will need to send to flashbots in order to execute this job, and then push an object containing those transactions along with the target block and id of each one to our `workableGroup`. 
+    To populate transactions for consequent blocks we use a for loop that will push as many objects to `workableGroups` as the keeper has passed as the `bundleBurst` parameter. In these objects, the array of populated transactions will always be the same, but the target block and the id will change.
+    If everything went well, `getWorkableTxs` sends an object containing the workable groups and the current job `correlationId` to the Keep3r-CLI, which will be received by `job-wrapper.ts`.
+    - The catch statement will catch any error and log out a message for the keeper to read. The most common error that will occur is that the job is currently in cooldown, therefore it can't be worked.
+    - The finally statement will kill the process once it has concluded.
+    - Lastly, and outside the `getWorkableTxs` function, we export `getWorkableTxs`.
+
+    This is the shared structure among jobs and it's exactly the structure that can be found in the `JobA` example we provide. However, some jobs will have protocol-specific logic that will modify this structure ever-so-slightly. 
+    
+    For example: some jobs will have multiple strategies that need to be run. Others will require the keeper to call a function before calling the `work` function. For these two cases we have provided examples that show how to modify the basic structure to add protocol-specific features:
+    
+    - Strategies are covered in `harvest-v2`, `tend-v2`, `tend-v2-2`.
+    - Jobs that require a previous function to be called is covered in `dca`
+    - Jobs that use relayers are covered in `harvest-v2`, `jobAStealth`
+
+If you still have doubts as to how to implement a script for your job, reach out to us!

commitlint.config.js

@@ -0,0 +1 @@
+module.exports = { extends: ['@commitlint/config-conventional'] };