add script for rebuilding dev environment #7256#7363
Conversation
| rm -rf $PAYARA_DIR/glassfish/domains/domain1/generated | ||
|
|
||
| echo "Deleting ALL DATA FILES uploaded to Dataverse..." | ||
| rm -rf $PAYARA_DIR/glassfish/domains/domain1/files |
There was a problem hiding this comment.
since you can change this location, can this be determined from the jvm option instead of hardcoded?
There was a problem hiding this comment.
I had that thought, that perhaps some devs keep their data files somewhere other than default (domain1/files). I figured I'd wait until there's demand to make this configurable. We could either add a variable to the top called something like DATA_FILES_DIR or yes, perhaps pull it out from asadmin list-jvm-options.
There was a problem hiding this comment.
OK, I'm fine with pushing that to later. Could you a) add that as a todo comment and b) add a note in the docs to point out that files would have to be in the default location?
scripts/dev/dev-rebuild.sh
Outdated
| echo "Deleting ALL DATA FILES uploaded to Dataverse..." | ||
| rm -rf $PAYARA_DIR/glassfish/domains/domain1/files | ||
|
|
||
| echo "Terminating database settings so we can drop the database..." |
There was a problem hiding this comment.
just because I'm curious, what does this do?
There was a problem hiding this comment.
I'm assuming you mean the pg_terminate_backend stuff. It's just a SQL statement I found online somewhere. I didn't dig into it. In practice, it's sometimes necessary to terminate all sessions because you've got a session or two left over from pgAdmin or a terminal. In my experience, you can drop a database with open sessions.
There was a problem hiding this comment.
Ah, makes sense. I was confused by "Terminating database settings". I think that's a typo and should be "sessions".
There was a problem hiding this comment.
Oh, a typo. I meant sessions, not settings. Fixed in d3778f3.
What this PR does / why we need it:
Sometimes developers benefit from dropping their database. This script does that and the subsequent setup so that API test can run.
Which issue(s) this PR closes:
Closes #7256
Special notes for your reviewer:
As mentioned in the issue and tech hours today, I've been using a variation of this script for years. That script was also in use on the phoenix server for years.
Suggestions on how to test this:
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
No.
Is there a release notes update needed for this change?:
Probably not worth mentioning.
Additional documentation:
Just the included dev guide update.