feat: setup for running checks locally #29
Conversation
|
|
||
| } else { | ||
| // Running in CI, save to file on REPORTS_BRANCH | ||
| const { github } = await import("./utils/clients/github"); // lazy load to avoid errors about missing env vars when not in CI |
There was a problem hiding this comment.
i would probably do this slightly differently, where you just have a different entry point for main and local testing, but you can probably also just use something like is the github token to enter this code path
also would be cool if our testing was scripted (integration testing) for ongoing maintenance, but that's a lot of work
There was a problem hiding this comment.
i would probably do this slightly differently, where you just have a different entry point for main and local testing, but you can probably also just use something like is the github token to enter this code path
Yea different entry point could work also, but probably would want to pull out some of the existing code into standalone methods to avoid duplicating code. My thinking was this is the shortest path forward to knocking out the bigger unknowns (e.g. tx simulation), then could refactor later
use something like is the github token to enter this code path
Do you mean remove the RUNNING_LOCALLY flag and use the presence of the GitHub API keys in its place? Can do that, but do you know what env vars to check for? new Octokit() threw with a missing GITHUB_ACTION env var and I didn't see that defined anywhere in the CI config, so that was confusing
also would be cool if our testing was scripted (integration testing) for ongoing maintenance, but that's a lot of work
Could you create an issue with some more details on what you had in mind here?
There was a problem hiding this comment.
Yea different entry point could work also, but probably would want to pull out some of the existing code into standalone methods to avoid duplicating code. My thinking was this is the shortest path forward to knocking out the bigger unknowns (e.g. tx simulation), then could refactor later
agree, you would want both entry points to call into the report generator code, where the cli entry point writes the output to console, (or somewhere useful for manual testing), takes cli arguments for which governor and/or proposal to check, etc.
and the ci entry point saves report results to the repo
it shouldn't be a large refactor, but i'm ok with doing it later
Do you mean remove the RUNNING_LOCALLY flag and use the presence of the GitHub API keys in its place?
yeah, you only need to check the one GITHUB_TOKEN i think
created #31
There was a problem hiding this comment.
Cool that all makes sense, thanks 👌
| @@ -1,3 +1,3 @@ | |||
| node_modules | |||
| .idea | |||
|
|
|||
| reports/ | |||
There was a problem hiding this comment.
Good call, must have been using my global gitignore. Done in 6bd5777
See
README.mdfor details on the new environment variable configurationINFURA_API_KEYwithRPC_URLto remove Infura dependence (need to change this in repo secrets for CI to pass)reportsfolder when running locally