You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: DEVELOPING.md
+8-22Lines changed: 8 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,18 @@
1
-
# Contributing
1
+
# Developing
2
2
3
-
This file will guide you through the process of getting to project up and running, in case you want to provide coding contributions.
3
+
This file will guide you through the process of getting to project up and running, in case you want to work on it locally.
4
4
5
-
You will also see how to ensure the code fulfills the expected code checks, and how to create a pull request.
5
+
You will also see how to ensure the code fulfills the expected code checks, and verify it meets expected quality.
6
6
7
7
## System dependencies
8
8
9
9
The project provides all its dependencies as docker containers through a `docker compose` configuration.
10
10
11
-
Because of this, the only actual dependencies are[docker](https://docs.docker.com/get-docker/) and [docker compose](https://docs.docker.com/compose/install/).
11
+
Because of this, the only actual dependency is[docker](https://docs.docker.com/get-docker/).
12
12
13
13
## Setting up the project
14
14
15
-
The first thing you need to do is fork the repository, and clone it in your local machine.
15
+
The first thing you need to do is clone the repository in your local machine.
16
16
17
17
Then you will have to follow these steps:
18
18
@@ -22,7 +22,7 @@ Then you will have to follow these steps:
The `shlink_dev_env.php` file is gitignored, so you can customize it as you want. For example, by adding your own GeoLite license key.
25
+
The `shlink_dev_env.php` file is git-ignored, so you can customize it as you want. For example, by adding your own GeoLite license key.
26
26
27
27
* Start-up the project by running `docker compose up`.
28
28
@@ -34,9 +34,9 @@ Then you will have to follow these steps:
34
34
* Run `./indocker bin/cli db:migrate` to get database migrations up to date.
35
35
* Run `./indocker bin/cli api-key:generate` to get your first API key generated.
36
36
37
-
Once you finish this, you will have the project exposed in ports `8800` through RoadRunner and `8000` through nginx+php-fpm.
37
+
Once you finish this, you will have the project exposed in ports `8800` through RoadRunner, `8008` through FrankenPHP and `8000` through nginx+php-fpm.
38
38
39
-
> Note: The `indocker` shell script is a helper tool used to run commands inside the main docker container.
39
+
> Note: The `indocker` shell script is a helper tool used to run commands inside the main RoadRunner docker container.
40
40
41
41
## Project structure
42
42
@@ -111,8 +111,6 @@ In order to ensure stability and no regressions are introduced while developing
111
111
112
112
They use Maria DB as the database engine, and include the same fixtures as the API tests, that ensure the same data exists at the beginning of the execution.
113
113
114
-
Depending on the kind of contribution, maybe not all kinds of tests are needed, but the more you provide, the better.
115
-
116
114
## Running code checks
117
115
118
116
* Run `./indocker composer cs` to check coding styles are fulfilled.
@@ -135,18 +133,6 @@ The project provides a Swagger UI container for dev envs, which can be accessed
135
133
136
134
It will automatically load the contents of `docs/swagger`, so you can make any updates and they will get reflected.
137
135
138
-
## Pull request process
139
-
140
-
**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.
141
-
142
-
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.
143
-
144
-
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.
145
-
146
-
The base branch should always be `develop`, and the target branch for the pull request should also be `develop`.
147
-
148
-
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.
149
-
150
136
## Architectural Decision Records
151
137
152
138
The project includes logs for some architectural decisions, using the [adr](https://adr.github.io/) proposal.
0 commit comments