Open haveyaseen opened 4 years ago
Any pointers on the commands needed to setup the environment and to run the tests?
@Addono As far as I know:
go test -v github.com/ito-org/go-backend
go run github.com/ito-org/go-backend
cc @calmandniceperson
@Addono For both testing and running the backend application you need to have Postgres running. I'm going to make some changes so you can spin up the database without prior configuration.
Once Postgres is up and running, we need go test github.com/ito-org/go-backend
to work. Deployment (I wouldn't know where to deploy it currently) would work through go install github.com/ito-org/go-backend
.
Deployment seems like a separate issue to me, which should also be included in CI but not defined by it.
Anyway, I would suggest containerizing it or trying to run it on serverless (e.g. on Zeit Now or AWS using the Serverless Framework).
Serverless is more experimental and probably requires some changes in the code, on the plus side once it's running "it just works" and the only thing you need to worry about is paying the bill once you exceed the free-tier.
Containerizing and running containers will require more configuration and managing infrastructure, hence making it easier to misconfigure and as such suffer down time. However, this option definitely has more flexibility, e.g. adding rate limiting (#4) on your reverse proxy.
If you just need an MVP, then you could always spin up a VM and manually install everything. However, this "pet server" is not future proof, as it doesn't scale and won't be able to recover by itself.
Currently #8 is blocking progress.
@Addono Could you try basing your branch on the dev branch, please?
Also, when supplying variables such as POSTGRES_PASSWORD to the Postgres container, you can supply these credentials to the backend application through the environment variables POSTGRES_PASSWORD
, POSTGRES_USER
, and POSTGRES_DB
.
Yeah, I noticed. The next thing which breaks is caused by having a hard requirement on a .env
file, for one because it feels like an anti-pattern where you need to supply an (empty) file if you want to set them using the environment. More importantly, it breaks the docker-compose up flow, as the .env is not included after building the image (only the build artifact is copied over).
For now this worked:
The most recent commits to the dev branch changed that. Removing it from the docker-compose file is the next step.
So, I am getting some results. The tests fail, however the error message is not really helpful for my eyes. https://github.com/Addono/api-backend/runs/602239783?check_suite_focus=true
Are the tests supposed to pass now? The version is based on a recently rebased version from dev.
You should also add the gosec security scanner and run a linter. You can add these jobs:
- name: Run Gosec Security Scanner
uses: securego/gosec@master
with:
args: ./...
- name: Test
run: docker run --rm -v $(pwd):/app -w /app golangci/golangci-lint:v1.24.0 golangci-lint run -v
@Addono What it's saying is: The test expected a http status code 200, but got a 500. This probably means the endpoint handler errored.
Yeah, looked into the DB logs, which needed to be initialized.
On my fork the tests are now passing, however it's based on the dev branch. How should I PR? Including or excluding the commits on dev?
You should also add the gosec security scanner and run a linter. You can add these jobs:
- name: Run Gosec Security Scanner uses: securego/gosec@master with: args: ./... - name: Test run: docker run --rm -v $(pwd):/app -w /app golangci/golangci-lint:v1.24.0 golangci-lint run -v
I added them as separate jobs, however they both fail. https://github.com/Addono/api-backend/runs/603000917?check_suite_focus=true
I fixed most of those issue in a different branch #10
Add GitHub Actions workflow.