use postgres and EF migrations#8
Conversation
…actually control sets of labels
… initial database
|
Needs integration test for repository. |
|
added test |
| @@ -0,0 +1,12 @@ | |||
| services: | |||
There was a problem hiding this comment.
This change would mean that using docker compose up wouldn't actually start the labeller. It would only start a local postgres db. The docker compose is to be used in prod as well.
SS14.Labeller/Database/Migrations/001_CreateTable_DiscourseTopics.cs
Outdated
Show resolved
Hide resolved
README.md
Outdated
| ### Debugging behaviour in container | ||
|
|
||
| To debug app behaviour in container environment you can use docker-compose-debug.yaml (it will pick latest version of labeller app from image repository): | ||
| ``` | ||
| docker compose -f docker-compose-debug.yml up -d | ||
| ``` | ||
| Or build Dockerfile yourself to try out your local code. No newline at end of file |
There was a problem hiding this comment.
Feels kinda sus, unsure. Shouldn't local docker compose files not use the images from the registry? You would want to test your own changes, no?
There was a problem hiding this comment.
I was under impression that prod is not using docker-compose, i guess its better to discuss what do we exactly want. I added this one because its the fastest way to start infrastructure locally - you just go
docker compose up
and you then start application locally for debug - very nice stuff. If we use docker-compose on prod - it should contain application, but i am not 100% sure how we do that... and i am also not sure its a good idea to use docker-provided postgres - we need to think ahead, if it will contain data, loss of which will be major PITA to project as a whole. We probably would need good postgres instance with backups, metrics and alerts for jetfish - why not let it live with that thing and think about it a little bit ahead of time?
| Microsoft Visual Studio Solution File, Format Version 12.00 | ||
| # Visual Studio Version 17 | ||
| VisualStudioVersion = 17.13.35818.85 d17.13 | ||
| VisualStudioVersion = 17.13.35818.85 |
There was a problem hiding this comment.
pepeHands when will M$ release xml-based sln files, ffs
SS14.Labeller/appsettings.json
Outdated
| "ConnectionStrings":{ | ||
| "Default": "Data Source=data/Application.db" | ||
| "ConnectionStrings": { | ||
| "Default": "Host=localhost;Port=5432;Username=labeller_user;Password=example;Database=labeller;" |
There was a problem hiding this comment.
Usually for your local postgres instances the password is "postgres" and the user is also "postgres", change it to this
| "linux/arm64") export RID=linux-arm64 ;; \ | ||
| *) echo "Unsupported TARGETPLATFORM: $TARGETPLATFORM" && exit 1 ;; \ | ||
| esac \ | ||
| && dotnet publish -c Release -r $RID --self-contained true /p:PublishAot=true -o /app |
There was a problem hiding this comment.
This would make the container not run since the dotnet runtime is not in the container
There was a problem hiding this comment.
--self-contained true is still there - why would there be problem with that?!
Tested it with this Dockerfile and got no 'missing dotnet' problem :/ am i doing something wrong?
There was a problem hiding this comment.
Oh right! Yeah. Though for download size it would probably be best that the Docker image your standard dotnet runtime image since then users won't have to download the runtime twice if they already had a docker image with it.
There was a problem hiding this comment.
So you would better like to have 9.0.9-alpine3.22 here instead of what it currently uses?
2 participants
No description provided.