mirrors/shlink
1
0
Fork 0
mirror of https://github.com/shlinkio/shlink.git synced 2025-03-14 04:00:57 +03:00
Code Issues Projects Releases Packages Wiki Activity

Improvements in CONTRIBUTING doc

Browse source
This commit is contained in:
Alejandro Celaya 2021-02-02 21:19:38 +01:00
parent 36a172308a
commit 31a7212a71
1 changed files with 12 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
CONTRIBUTING.md
View file

@ -33,7 +33,7 @@ Then you will have to follow these steps:
Once you finish this, you will have the project exposed in ports `8000` through nginx+php-fpm and `8080` through swoole.
> Note: The `indocker` shell script is a helper used to run commands inside the main docker container.
> Note: The `indocker` shell script is a helper tool used to run commands inside the main docker container.
## Project structure
@ -88,9 +88,9 @@ In order to ensure stability and no regressions are introduced while developing
* **Unit tests**: These are the simplest to run, and usually test individual pieces of code, replacing any external dependency by mocks.
The code coverage of unit tests is pretty high, and only entity repositories are excluded because of their nature.
The code coverage of unit tests is pretty high, and only components which work closer to the database, like entity repositories, are excluded because of their nature.
* **Database tests**: These are integration tests that run against a real database, and only cover entity repositories.
* **Database tests**: These are integration tests that run against a real database, and only cover components which work closer to the database.
Its purpose is to verify all the database queries behave as expected and return what's expected.
@ -98,7 +98,7 @@ In order to ensure stability and no regressions are introduced while developing
* **API tests**: These are E2E tests that spin up an instance of the app and test it from the outside, by interacting with the REST API.
These are the best tests to catch regressions, and to verify everything interacts as expected.
These are the best tests to catch regressions, and to verify everything behaves as expected.
They use MySQL as the database engine, and include some fixtures that ensure the same data exists at the beginning of the execution.
@ -114,13 +114,14 @@ Depending on the kind of contribution, maybe not all kinds of tests are needed,
* Run `./indocker composer test:unit` to run the unit tests.
* Run `./indocker composer test:db` to run the database integration tests.
This command runs the same test suite against all supported database engines. If you just want to run one of them, you can add one of `:sqlite`, `:mysql`, `:maria`, `:postgres`, `:mssql` at the end of the command.
This command runs the same test suite against all supported database engines in parallel. If you just want to run one of them, you can add one of `:sqlite`, `:mysql`, `:maria`, `:postgres`, `:mssql` at the end of the command.
For example, `test:db:postgres`.
* Run `./indocker composer test:api` to run API E2E tests. For these, the MySQL database engine is used.
* Run `./indocker composer infect:test` ti run both unit and database tests (over sqlite) and then apply mutations to them with [infection](https://infection.github.io/).
* Run `./indocker composer ci` to run all previous commands together. This command is run during the project's continuous integration.
* Run `./indocker composer ci:parallel` to do the same as in previous case, but parallelizing non-conflicting tasks as much as possible.
> Note: Due to some limitations in the tooling used by shlink, the testing databases need to exist beforehand, both for db and api tests (except sqlite).
>
@ -130,11 +131,15 @@ Depending on the kind of contribution, maybe not all kinds of tests are needed,
## Pull request process
In order to provide pull requests to this project, you should always start by creating a new branch, where you will make all desired changes.
**Important!**: Before starting to work on a pull request, make sure you always [open an issue](https://github.com/shlinkio/shlink/issues/new/choose) first.
This is important because any contribution needs to be discussed first. Maybe there's someone else already working on something similar, or there are other considerations to have in mind.
Once everything is clear, to provide a pull request to this project, you should always start by creating a new branch, where you will make all desired changes.
The base branch should always be `develop`, and the target branch for the pull request should also be `develop`.
Before your branch can be merged, all the checks described in [Running code checks](#running-code-checks) have to be passing. You can verify that manually by running `./indocker composer ci`, or wait for the build to be run automatically after the pull request is created.
Before your branch can be merged, all the checks described in [Running code checks](#running-code-checks) have to be passing. You can verify that manually by running `./indocker composer ci:parallel`, or wait for the build to be run automatically after the pull request is created.
## Architectural Decision Records