-
Notifications
You must be signed in to change notification settings - Fork 74
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
add steps for pulling staging data in windows #502
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did an initial pass. Leaving more specific comments about writing style up to @vossisboss
README.md
Outdated
The ones for the web container and local machine are somewhat more straightforward to run. I used the VS code editor, and the terminal in it. More than one terminal instance is required for the `web` container and local commands, but the db container instructions should be done from within the Docker terminal. | ||
|
||
Spotting whether a command should be run in the `web` or `db` is a matter of looking at the second argument passed to dexec() when invoked. | ||
|
||
The commands, the location, and the order in which to run them are as follows: | ||
|
||
1. `heroku pg:backups:download --output=here.dump --app wagtail-org-staging`. To avoid less typing, Substitute the `original{LOCAL_DUMP_DIR}/{datestamp}.dump}` with `here.dump`. Also substitute the `app_instance` variable with the literal `wagtail-org-staging`. Run this on your local terminal instance. | ||
2. The next command is to be run within the `db` container, so open it and type `dropdb --if-exists --host db --username=wagtailorg wagtailorg`. | ||
3. Afterwards, still in the `db` container, run `createdb --host db --username=wagtailorg wagtailorg`. | ||
4. The next command involves connecting the local postgres DB using `psql`. For this, run the following in the `db` container: `psql -d wagtailorg -U wagtailorg -c "CREATE SCHEMA heroku_ext;"` | ||
5. Still in the db container, run the following command for importing the database file to the `db` container: `pg_restore --clean --no-acl --if-exists --no-owner --host db --username=wagtailorg -d wagtailorg /app/here.dump `. This is possible if you also named the dump file `"here.dump"` as I did in step 1. | ||
6. The next command to run is to be in the web container (in one of the open terminals on possibly your VS code editor, after previously running `make sh`). It is: `psql -c "UPDATE wagtailcore_site SET hostname = 'localhost', port = 8000 WHERE is_default_site IS TRUE;"`. | ||
7. The last command to run is in the local terminal, and it is `rm here.dump`. | ||
|
||
With `npm` installed, you can run `npm install` directly, since nvm isn't supported for Windows (non-POSIX). Optionally, you can use `fnm` to first switch to the appropriate version of node. | ||
|
||
Afterwards, the recommended next step would be setting up your [frontend tooling.](#frontend-tooling-docker-and-vagrant) | ||
|
||
## Deployment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered using docker compose run db <command to run in container>
? I think this makes it much easier for users to run commands in a container. You can just list a series of commands to run to accomplish whatever fab pull-staging-data
is doing.
Overall, my impression of this section is that it is overly 'dense' (too many words) compared to other sections of the README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stormheg Thanks for the initial pass. I think he's right about the style suggestions @Chiemezuo. I've made some suggested changes that should address that.
I'm curious hos everyone feels about maintaining this section in our documentation over the long-term. Since most of us lack Windows machines, it might be wiser to link to Chiemezuo's gist rather than try to keep up with a whole new section in our docs. Thoughts? Ideas?
I could go either way and I'd like to know if anyone else has strong opinions.
Right! What do you think? @Stormheg @cnk @vossisboss |
Who says a separate gist will be maintained over time? From my perspective, the README file for this repository is the superior place to keep instructions like this. Visible and editable by all. Admittedly, the instructions are likely to go bad over time. We can address that when as it is reported, updating them might make for a good contribution by someone new who comes along. |
Thanks for the input @Stormheg. @Chiemezuo Make those updates and then we can get this merged. |
Are we up for another round of reviews? @vossisboss @Stormheg |
This is a way I think we could incorporate a caveat for contributors who use Windows machines and might want to pull staging data.
cc @vossisboss