Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Chiemezuo
Copy link
Contributor

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

Copy link
Member

@Stormheg Stormheg left a 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
Comment on lines 150 to 168
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
Copy link
Member

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.

Copy link
Contributor

@vossisboss vossisboss left a 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.

@Chiemezuo
Copy link
Contributor Author

Right!
Before I implement the suggestions, Meagen has a really great point. If this won't be maintained by Windows users in the long run, it might not make as much sense to write all of this directly here. A separate gist might be a better option.

What do you think? @Stormheg @cnk @vossisboss

@Stormheg
Copy link
Member

Stormheg commented Feb 21, 2025

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.

@vossisboss
Copy link
Contributor

Thanks for the input @Stormheg. @Chiemezuo Make those updates and then we can get this merged.

@Chiemezuo
Copy link
Contributor Author

Are we up for another round of reviews? @vossisboss @Stormheg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants