leepeuker / movary

Self hosted web app to track and rate your watched movies
MIT License
388 stars 14 forks source link

Refactor testing pipeline #592

Open JVT038 opened 6 months ago

JVT038 commented 6 months ago

I have generated HTTP tests for all endpoints defined in the OpenAPI specs.

Used command:

docker run --rm \
    -v "${PWD}:/local" openapitools/openapi-generator-cli generate \
    -i /local/docs/openapi.json \
    -g jetbrains-http-client \
    -o /local/movaryClient \
    --skip-validate-spec

I think the addition of @name is a good one, because it makes it easier for us to see which tests have failed / passed.

Besides that, this PR can be used as a start to test all the endpoints, because we can now just copy-paste the very basics into the tests/rest/api directory (where we'll be placing the actual tests).

I have also changed the testing workflow, renaming run_tests to run_php_tests and adding run_http_tests which should automatically run all the HTTP tests in the HTTP directory (not tested if this works though).

This PR is just a draft, meant as an example, not as an actual solution.

Some references:

JVT038 commented 5 months ago

I have changed some stuff and I think this is now a proper CI pipeline suitable for merging into main.

The pipeline no longer builds and runs a local docker image of Movary; instead, it uses the native PHP built-in webserver, which is faster than building a Docker image each time. Additionally, a MySQL server is running in the background, which is provided by the service containers feature from GitHub Actions.

We could add run the tests twice; once for the MySQL database and once for the SQlite3 database.

Anyway, the PHP server now runs in the background, allowing the ijhttp CLI tool to run the HTTP API tests in the foreground. When the API tests are finished, the PHP server gets killed and the workflow starts wrapping up and removing the MySQL containers.

leepeuker commented 5 months ago

The pipeline no longer builds and runs a local docker image of Movary; instead, it uses the native PHP built-in webserver

That is not something I want to go for. Every environment and build step should use the same docker setup. This guarantees our builds to be reproducible and isolated in all environments.

JVT038 commented 5 months ago

I have managed to fix the CI pipeline and ensure that it all runs inside a docker container that's created from the Dockerfile image.