This Github Actions integrated bot lints EIPs and provides feedback for authors, its goal is to catch simple problems and merge simple changes automatically.
on: [pull_request]
jobs:
hello_world_job:
runs-on: ubuntu-latest
name: EIP Auto-Merge Bot
steps:
- name: auto-merge-bot
uses: ./.github/bot
id: auto-merge-bot
env:
GITHUB_TOKEN: ${{ secrets.TOKEN }}- node package manager (npm)
- Github Token
- Forked Repo
- nodejs
- Download your forked
EIPSrepo - Create a Github Token
- Create a PR in your forked repo doing anything, I recommend just editing a couple lines in an already existing EIPs
- Create a .env variable in the root dir with the following information defined:
GITHUB_TOKEN = <YOUR GITHUB TOKEN>
NODE_ENV = development
PULL_NUMBER = <pull_number>
BASE_SHA = <base sha of the PR>
HEAD_SHA = <head sha of the PR>
REPO_OWNER_NAME = <your login>
REPO_NAME = EIPs
GITHUB_REPOSITORY = <your login>/EIPs
npm run it
- When I run it, I'm getting unexplainable errors with my github requests.
- Github limits the number requests from a given IP, this may be avoidable if you only use the
octokitbut a VPN also works just fine
- Github limits the number requests from a given IP, this may be avoidable if you only use the
This repo is a living repo, and it will grow with the EIP drafting and editing process. It's important to maintain code quality.
- Define every type (including octokit)
- Make clean and clear error messages
- Avoid abstraction
- Use enums as much as possible
A couple things to keep in mind if you end up making changes to this
Define every type, no any types. The time it takes to define a type now will save you or someone else later a lot of time. If you make assumptions about types, protect those assumptions (throw exception if they are false).
Sometimes Octokit types can be difficult to index, but it's important that whenever possible the types are defined and assumptions protected.
This bot has a single goal: catch simple mistakes automatically and save the editors time. So clear error messages that allow the PR author to change it themselves is very important.
Only abstract if necessary, keep things in one file where applicable; other examples of okay abstraction are types, regex, and methods used more than 3 times. Otherwise, it's often cleaner to just re-write things.
// DON'T DO THIS
** src/lib.ts **
export const baz = () => "baz"
** src/foo.ts **
import { baz } from "./lib"
export const foo = () => baz();
** src/bar.ts **
import { baz } from "./lib"
export const bar = () => baz();
// DO THIS
** src/foo.ts **
const baz = () => "baz"
export const foo = () => baz();
** src/bar.ts **
const baz = () => "baz"
export const bar = () => baz();In short, enums make code easier to read, trace, and maintain.
But here's a brief info if you haven't worked with them before
enum EnumFoo {
bar = "BAR",
baz = "BAZ"
}
type Foo = "BAR" | "BAZ"Inline declaraion is maintained
const foo: EnumFoo
const bar: Foo
// foo and bar both must be either "BAR" or "BAZ"Use case is slightly different
const foo: EnumFoo = EnumFoo.baz // you can't directly assign "BAZ"
const bar: Foo = "BAZ"But comparisons are maintained
// taking variables from above
("BAZ" === foo) === ("BAZ" === bar)
&&
("BAZ" === EnumFoo.baz) === ("BAZ" === "BAZ")In addition to the above use case and string eradication it centralizes the strings to be matched so they can be easily changed. So, making life much easier if you wanted to change the names of statuses on an EIP.
- @alita-moore
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent