-
Notifications
You must be signed in to change notification settings - Fork 16
Fix/jhu nyc support #272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/jhu nyc support #272
Conversation
* update cache * remove default end_date * update start_date * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cache * update cahce * Set up initial google_health-deploy branch - Add new google_health Jenkins pipeline stage scripts - Add the abilty for Ansible to write either a file or a template depending on which has been configured for the indicator - Add Ansible template directory (special tall bookshelf) - Add the ability to keep sensitive variables in `vault.yaml` - Add google_health production params template Encrypt vault.yaml * Use templates dir * Remove end date from params * Switch to midas export dir * Properly rename Jenkins pipeline stage scripts * Handle google_health's testing needs - Add: Ansible playbook for securely handling placing the `params.json` template we need for testing. This will happen during the Jenkins build stage when we are setting up the venv in the workspace on the Jenkins server. - Add: Test `params.json` template. - Add: Jenkins user variable. - Fix: Was incorrectly trying to use a file instead of a template in `ansible-deploy.yaml`. - Add: Call the small Ansible playbook from the Jenkins build wrapper. * Change to the Ansible root dir before trying to do Ansible things * Delegate to localhost * Tell Ansible we want to connect locally for this playbook * Remove set -x from Bash scripts * Add initial Jenkins/Ansible necessities for CI/CD and Automation - Add Jenkins pipeline scripts - Add production params template - Update vars and vault files with AWS secrets * Remove ght cache files * Disable pylint convention messages * Work around linter errors Co-authored-by: Addison Hu <[email protected]> Co-authored-by: Jingjing Tang <[email protected]>
Merge main into deploy-google_health
Deploy jhu
* Add updated encrypted credentials * Add wip_signal to production params template * Add newline * Run on 12 cores * Add shell script to run the indicator
* Add updated encrypted credentials * Add wip_signal to production params template * Add newline * Run on 12 cores * Add shell script to run the indicator * Update run script - Use production ingestion dir - Remove hard fail to work around an issue with `cp`. - `cp` fails when files don't exist. I thought we could squash the error by sending stderr to /dev/null, but `set -eo` still catches and fails the script. Even worse, it happens silently. There should be a better way to handle this so will add it to a future task.
Merge the SafeGraph deployment branch updates to main
Details on failed check: Linting causes a recursion error starting with this stack trace:
Changing a static file should not have caused a new linting error. @huisaddison did you branch from deploy-jhu, main, or some other branch? |
I branched off of My only two commits are:
I really don't know where to begin debugging this. Maybe @korlaxxalrok / @dshemetov can help since it seems to be jenkins related? |
@krivard I undid my commits locally ( |
@huisaddison Branching from main is the correct workflow, no worries there. What that does tell us is that some change to the JHU code was merged to main without going through deploy-jhu first. |
@krivard I was going to do a git bisect (@capnrefsmmat 's idea), but I am finding the same linter error with my HEAD pointed at |
I've gone to nearly the beginning of time |
FWIW, linter for |
Oh ffs, it's apparently a common regression failure in astroid, one of the components of pylint. There must have been an inopportune version bump somewhere. Possibly an intersection with pandas as well. Some similar problems have had luck downgrading astroid; give that a shot? |
Not sure how...? Seems that |
@krivard Ugh so I manually installed pylint==2.3.1 and astroid==2.2.5 in the venv (which fixes it for the others that you linked) but I'm still getting the failure (but maybe due to another package that astroid doesn't like? linter seems to run for longer before failing, but maybe my mind is just playing tricks with me) |
@huisaddison Can we relatively safely disable the linter? We seem to have astroid What about using another linter locally for a sanity check, and then we can disable pylint so that Jenkins is happy? Not ideal, but it would at least provide for a decent local check before we deploy new code. |
FWIW, I just pulled this branch locally and am getting no linter errors with |
Yeah, same here. Extra wacky now. I am going to try to submit another PR with a branch based off of |
@dshemetov @korlaxxalrok Wow, so weird. :| Checked again and I still get those errors locally.
Could it be as subtle as Python / OS version? In any case, @korlaxxalrok whether or not we should allow ourselves to disable pylint for this particular pipeline sounds like a @krivard -level decision |
Could be something like that, yeah. Probably need to dig a bit more on the Jenkins server. Agreed, deferring to @krivard on the option to lint locally for sanity's sake and then disabling in Jenkins for the quick ⚒️ |
I'm happy with linting locally -- shall I merge #274 or do we need something fancier? |
I was gonna just test with #274, but if it works we can go with it. Otherwise we can make the same change in this one. |
@huisaddison wow, yes, so I think it's the combination of Python 3.8.3 plus those other packages. Just installed a fresh virtualenv with 3.8.3 and am getting the error now. |
Okay, since Dmitry was able to lint with a different Python version, I'm willing to say #274 is good. Closing this PR in favor of that one. |
Resolves #256 to account for the fact that JHU is now reporting borough-level cases. (Also removes unused detritus)
Diff of old and new county incidence prop for yesterday: