External Contributor Troubleshooting

[conbrad]

Hey @jmetev1 , I'm pulling your question over to discussions here since we'll lose track of the PR discussion pretty quick.

i'm also trying to run the whole app so i can do stuff requiring the backend. i've been trying to follow instructions using docker compose in root readme. but getting poetry errors. am i following the right instructions to start with? i also tried the instructions in Developing the application in a dev container, using vscode: but there is no such thing as docker-compose.vscode.yml

Yes, looks like those instructions are also out of date unfortunately. Dev containers are something I also haven't introduced to my workflow yet, but it looks like we have our dev container defined in the ./devcontainer folder. I'll try and see if that's what we should be pointing at.

[jmetev1]

thank you. so right now people are generally just running api or other stuff independently without docker on their locals? i could probably figure that out if that's the norm.

[conbrad]

Yep, you'll just need:

• postgres locally on port 5432
• redis locally on port 6379
• api running via either
  • the api launch config command in vscode
  • make run in your terminal
• frontend running via either
  • yarn start in your terminal
  • the Chrome launch config command in vscode (I haven't used this in awhile either)

Side note:
vscode just prompted me to open the project in a dev container upon startup and that seems to be building so far...

[conbrad]

[conbrad]

Also I guess this information should be more obvious in the READMEs... I can address that.

[jmetev1]

ha ok i changed my mind. everything i've ever done with python outside of docker has been pyenv mess. maybe i'll try and fix the docker compose setup instead. i already got past the poetry part.

[conbrad]

Yeah that makes sense. I'm on my work machine right now which only has this and a couple other projects so it's easier to manage, that's good feedback.

The root dockerfile is what's used to build and deploy on our infrastructure. The dockerfile in /api is what's used to build and run the api locally -- it'd be nice if we just could settle on one, but there's some infrastructure details in the root one that's required for our cluster. We may in fact be able to settle on 1 if we can run build and run the root dockerfile locally.

Note: we're also running M1 macs locally and have had some incompatibility issues with some of our OS dependencies so that's another reason why we've stopped using docker development locally (these issues may be resolved after some time though).

[jmetev1]

hmm interesting. i'm on m1 pro so do you expect that i would have same issues or is it something specific to you?

i might be getting close with docker compose. i'm failing on alembic part of this bash -c "PYTHONPATH=. poetry run alembic upgrade head && poetry run uvicorn app.main:app --host 0.0.0.0 --reload --port 8080"

i do need the alembic part right?

i tried to move forward with the react upgrade but it's breaking the cypress tests and i can't really debug without a working server. one thing i considered is that i can disable auth on the frontend and point the frontend to the prod servers. but of course you have auth on api requests also. no way i can get around that easily eh? i assume it's not super private data.

[jmetev1]

current alembic errors are:
wps-api-1 | File "/app/alembic/versions/d9c05cb16869_add_combustible_area_data_to_advisory_.py", line 47, in upgrade
wps-api-1 | with get_fuel_types_from_object_store() as fuel_types:
wps-api-1 | File "/usr/lib/python3.10/contextlib.py", line 135, in enter
wps-api-1 | return next(self.gen)
wps-api-1 | File "/app/app/auto_spatial_advisory/calculate_combustible_land_area.py", line 37, in get_fuel_types_from_object_store
wps-api-1 | fuel_types_layer = fuel_types.GetLayer()
wps-api-1 | AttributeError: 'NoneType' object has no attribute 'GetLayer'

[jmetev1]

Running upgrade 0669994d4089 -> d9c05cb16869, Add combustible area data to advisory_shapes

[conbrad]

i'm on m1 pro so do you expect that i would have same issues or is it something specific to you?

It might be a resolved issue now since a lot of our dependencies hadn't built out support yet back when we had tried it, and we haven't tried it since then to my knowledge.

Regardless, related to the errors you're seeing now:

i do need the alembic part right?

Yes alembic is our database migration tool, it'll need to run before the API connects to it. What it looks like is happening here is that migration requests data from our object store which requires credentials -- nothing wrong on your side, I'll need to figure out a solution for this. As a workaround you can comment out the up function of the body of the migration.

i tried to move forward with the react upgrade but it's breaking the cypress tests and i can't really debug without a working server. one thing i considered is that i can disable auth on the frontend and point the frontend to the prod servers. but of course you have auth on api requests also. no way i can get around that easily eh? i assume it's not super private data.

Yes this is another tricky one. What you can do as a workaround is remove the auth locally, take a look at this diff to see what you can remove: https://github.com/bcgov/wps/compare/remove-hfi-local-auth?expand=1