Skip to content

Commit 732889a

Browse files
authored
Merge pull request #509 from ukkopahis/doc-improvements
docs: contribution guidelines, update overview, git setup and usage, syntax&usability fixes, freeze mkdocs requirements, sudo nopasswd
2 parents d840775 + e1dcd3e commit 732889a

File tree

10 files changed

+406
-20
lines changed

10 files changed

+406
-20
lines changed

docs/Basic_setup/Networking.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,9 @@ An easy way to find out your IP is by typing `ip address` in the terminal and lo
55

66
Check the docker-compose.yml to see which ports have been used
77

8+
<div markdown="1" style="background: #FFFC; padding: 0.5em;">
89
![net](https://user-images.githubusercontent.com/46672225/66702353-0bcc4080-ed07-11e9-994b-62219f50b096.png)
10+
</div>
911

1012
## Examples
1113
- You want to connect your nodered to your mqtt server. In nodered drop an mqtt node, when you need to specify the address type `mosquitto`
@@ -25,4 +27,4 @@ For adminer:
2527
ports:
2628
- 9080:8080
2729
```
28-
Port 9080 on Host Pi is mapped to port 8080 of the container. Therefore 127.0.0.1:8080 will take you to openHAB, where 127.0.0.1:9080 will take you to adminer
30+
Port 9080 on Host Pi is mapped to port 8080 of the container. Therefore 127.0.0.1:8080 will take you to openHAB, where 127.0.0.1:9080 will take you to adminer

docs/Basic_setup/Understanding-Containers.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ In simple terms, Docker is a software platform that simplifies the process of bu
44
managing and distributing applications. It does this by virtualizing the operating system of the
55
computer on which it is installed and running.
66

7-
# The Problem
7+
## The Problem
88
Let’s say you have three different Python-based applications that you plan to host on a single server
99
(which could either be a physical or a virtual machine).
1010

@@ -14,7 +14,7 @@ libraries and dependencies, differ from one application to another.
1414
Since we cannot have different versions of Python installed on the same machine, this prevents us from
1515
hosting all three applications on the same computer.
1616

17-
# The Solution
17+
## The Solution
1818
Let’s look at how we could solve this problem without making use of Docker. In such a scenario, we
1919
could solve this problem either by having three physical machines, or a single physical machine, which
2020
is powerful enough to host and run three virtual machines on it.
@@ -34,7 +34,7 @@ This allows each container to be isolated from the other present on the same hos
3434
multiple containers with different application requirements and dependencies to run on the same host,
3535
as long as they have the same operating system requirements.
3636

37-
# Docker Terminology
37+
## Docker Terminology
3838

3939
Docker Images and Docker Containers are the two essential things that you will come across daily while
4040
working with Docker.
@@ -45,7 +45,7 @@ required to run that application on Docker.
4545
On the other hand, as stated earlier, a Docker Container is a logical entity. In more precise terms,
4646
it is a running instance of the Docker Image.
4747

48-
# What is Docker-Compose?
48+
## What is Docker-Compose?
4949

5050
Docker Compose provides a way to orchestrate multiple containers that work together. Docker compose
5151
is a simple yet powerful tool that is used to run multiple containers as a single service.
@@ -56,21 +56,21 @@ each separately. It wires up the networks (literally), mounts all volumes and ex
5656

5757
The IOTstack with the templates and menu is a generator for that docker-compose service descriptor.
5858

59-
# How Docker Compose Works?
59+
## How Docker Compose Works?
6060

6161
use yaml files to configure application services (docker-compose.yaml)
6262
can start all the services with a single command ( docker-compose up )
6363
can stop all the service with a single command ( docker-compose down )
6464

65-
# How are the containers connected
65+
## How are the containers connected
6666
The containers are automagically connected when we run the stack with docker-compose up.
6767
The containers using same logical network (by default) where the instances can access each other with the instance
6868
logical name. Means if there is an instance called *mosquitto* and an *openhab*, when openHAB instance need
6969
to access mqtt on that case the domain name of mosquitto will be resolved as the runnuning instance of mosquitto.
7070

71-
# How the container are connected to host machine
71+
## How the container are connected to host machine
7272

73-
## Volumes
73+
### Volumes
7474

7575
The containers are enclosed processes which state are lost with the restart of container. To be able to
7676
persist states volumes (images or directories) can be used to share data with the host.
@@ -89,7 +89,7 @@ Volumes are the preferred mechanism for persisting data generated by and used by
8989
While bind mounts are dependent on the directory structure of the host machine, volumes are completely
9090
managed by Docker. In IOTstack project uses the volumes directory in general to bind these container volumes.
9191

92-
## Ports
92+
### Ports
9393
When containers running a we would like to delegate some services to the outside world, for example
9494
OpenHAB web frontend have to be accessible for users. There are several ways to achive that. One is
9595
mounting the port to the most machine, this called port binding. On that case service will have a dedicated

docs/Basic_setup/What-is-sudo.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -45,3 +45,15 @@ Please try to minimise your use of `sudo` when you are working with IOTstack. He
4545
```
4646

4747
It takes time, patience and practice to learn when `sudo` is **actually** needed. Over-using `sudo` out of habit, or because you were following a bad example you found on the web, is a very good way to find that you have created so many problems for yourself that will need to reinstall your IOTstack. *Please* err on the side of caution!
48+
49+
## Configuration
50+
51+
To edit sudo functionality and permissions use: `sudo visudo`
52+
53+
For instance, to allow sudo usage without prompting for a password:
54+
```bash
55+
# Allow members of group sudo to execute any command without password prompt
56+
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
57+
```
58+
59+
For more information: `man sudoers`

docs/Developers/Git-Setup.md

Lines changed: 178 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,178 @@
1+
How to setup and use git for IOTstack development.
2+
3+
1. First, create a
4+
[fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) of
5+
SensorsIot/IOTstack on github. And
6+
[setup](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
7+
your ssh-keys.
8+
1. Clone your fork and setup your github username and email
9+
``` console
10+
$ git clone [email protected]:<username>/IOTstack.git
11+
$ cd IOTstack
12+
$ git config user.name <username>
13+
$ git config user.email <1234>+<username>@users.noreply.github.com
14+
```
15+
1. Add up the SensorsIot/IOTstack upstream
16+
``` console
17+
$ git remote add upstream https://github.com/SensorsIot/IOTstack.git
18+
```
19+
1. Configure for ease of operation
20+
``` console
21+
$ git config fetch.prune true
22+
$ git config remote.pushDefault origin
23+
$ git config --add remote.origin.fetch "^refs/heads/gh-pages"
24+
$ git config --add remote.upstream.fetch "^refs/heads/gh-pages"
25+
$ git config branch.master.mergeoptions "--no-ff"
26+
$ git config fetch.parallel 0
27+
$ git fetch --all
28+
```
29+
30+
## Make a pull-request
31+
32+
``` mermaid
33+
flowchart LR
34+
upstream["upstream (SensorsIOT)"] -- "1. git fetch + git checkout -b"
35+
--> local[local branch]
36+
local -- "2. git commit" --> local
37+
local -- "3. git push" --> origin["origin (your fork)"]
38+
origin -- "3. create github pull-request" --> upstream
39+
```
40+
41+
Please see [Contributing](index.md) for instructions on how to write commit
42+
messages.
43+
44+
``` console
45+
$ git fetch upstream
46+
$ git checkout -b <your-descriptive-branch-name> upstream/master
47+
...coding and testing...
48+
$ git add <your new or changed file>
49+
Check everything has been added:
50+
$ git status
51+
$ git commit
52+
$ git push
53+
```
54+
When you execute git push, its output should have a link for creating the
55+
pull-request to github.
56+
57+
## Common operations
58+
59+
### Show compact history with "git lg"
60+
61+
``` console
62+
$ git config alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
63+
```
64+
65+
### Remove branches of merged pull-requests.
66+
67+
When your pull-requests have been merged, their branches aren't needed anymore.
68+
Remove them to reduce clutter and distractions. The master branch is never
69+
deleted.
70+
71+
``` console
72+
$ git fetch --all
73+
$ git checkout master
74+
$ git branch -r --merged upstream/master | \
75+
grep -v origin/master$ | grep origin | sed 's/origin\///' | \
76+
xargs -I 'B' git push --delete origin B
77+
$ git branch --merged upstream/master | grep -v " master$" | \
78+
xargs -I'B' git branch -d B
79+
```
80+
81+
## Advanced topics
82+
83+
### Fetch all pull-requests as branches
84+
85+
This is handy for easily testing out other persons' suggested changes. The
86+
branches are of course fetch-only, and you can't push your own commits to them.
87+
88+
``` console
89+
$ git config --add remote.upstream.fetch +refs/pull/*/head:refs/remotes/upstream/pr-*
90+
$ git fetch upstream
91+
```
92+
93+
*Note:* Everything below requires this.
94+
95+
### Show up-to-date branches not merged
96+
97+
Branches that include the latest upstream/master, but are not merged to
98+
your current branch, are potentially mergeable pull-requests. This is useful
99+
for identifying which pull-requests you should be able to merge without
100+
conflict.
101+
102+
``` console
103+
$ git fetch upstream
104+
$ git branch -r --contains upstream/master --no-merged upstream/master
105+
```
106+
107+
### Check pull-requests on Github can be merged without conflicts
108+
109+
In git, the only way to know if a branch can be merged without a conflict, is
110+
by actually doing the merge. An alias to (re-)create a branch named
111+
`merge-test` and do merges into it:
112+
113+
``` console
114+
$ git config alias.test-pull-request-merge $'!f() { : git merge && \
115+
OPENPULLS=$(curl -s \'https://api.github.com/repos/SensorsIot/IOTstack/pulls?base=master&per_page=100\' | \
116+
grep "^.....number" | sed -E \'s/.* ([0-9]+),/ upstream\\/pr-\\1/\') && \
117+
git fetch upstream && git checkout -B merge-test upstream/master && \
118+
git branch -r --contains upstream/master --no-merged upstream/master | \
119+
grep upstream/pr- | sort - <(echo "$OPENPULLS") | \
120+
{ uniq -d; [[ "$1" ]] && echo "$1"; } | \
121+
xargs -I B sh -c "echo Merging B && \
122+
git merge --no-rerere-autoupdate --no-ff --quiet B || \
123+
{ echo ***FAILED TO MERGE B && exit 255; };" ;}; f'
124+
```
125+
126+
<!-- Old version using 'plain' commands
127+
``` console
128+
$ OPENPULLS=$(curl -s 'https://api.github.com/repos/SensorsIot/IOTstack/pulls?state=open&per_page=100' | \
129+
grep "^.....number" | sed -E 's/.* ([0-9]+),/ upstream\/pr-\1/')
130+
$ git fetch upstream && git checkout -B merge-test upstream/master && \
131+
git branch -r --contains upstream/master --no-merged upstream/master | \
132+
grep upstream/pr- | sort - <(echo "$OPENPULLS") | uniq -d | \
133+
xargs -I B sh -c "echo Merging B && \
134+
git merge --no-rerere-autoupdate --no-ff --quiet B || \
135+
( echo ***FAILED TO MERGE B && exit 255 )"
136+
```
137+
-->
138+
139+
140+
Then use this alias combined with `git checkout -`, returning your working copy
141+
back to the original branch if all merges succeeded:
142+
143+
``` console
144+
$ git test-pull-request-merge && git checkout -
145+
```
146+
147+
This merges all branches that are: a) currently open pull requests and b)
148+
up-to-date, i.e. contains upstream/master and c) not merged already and d) the
149+
optional provided argument. Note: won't ignore draft pull-requests. If it
150+
encounters a failure, it stops immediately to let you inspect the conflict.
151+
152+
!!! help "Failed merge?"
153+
154+
*If* there was a merge-conflict, inspect it e.g. using `git diff`, but
155+
don't do any real work or conflict resolution in the merge-test branch.
156+
When you have understood the merge-conflict and want to leave the
157+
merge-test branch, abort the failed merge and switch to your actual branch:
158+
159+
``` console
160+
$ git diff
161+
$ git merge --abort
162+
$ git checkout <your-PR-branch-that-resulted-in-the-conflict>
163+
```
164+
165+
### Check your branch doesn't conflict with any existing pull-request
166+
167+
When you intend to submit a pull-request you might want to check that it won't
168+
conflict with any of the existing pull-requests.
169+
170+
1. Commit all your changes into your pull request branch.
171+
2. Use the alias from the previous "Test all current pull-requests..."-topic
172+
to test merging your branch in addition to all current pull request:
173+
174+
``` console
175+
$ git test-pull-request-merge <your-pull-request-branch> && git checkout -
176+
```
177+
178+
If there is a merge-conflict, see "Failed merge?" above.

docs/Developers/index.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,25 @@
11
# Contributing
22

3+
We welcome pull-requests.
4+
5+
For larger contributions, please open an issue describing your idea. It
6+
may provide valuable discussion and feedback. It also prevents the unfortunate
7+
case of two persons working on the same thing. There's no need to wait for any
8+
approval.
9+
10+
!!! check "Development guidelines"
11+
* It-just-works - use good defaults that will work well for a first time user
12+
* Keep-it-simple - try to keep stuff beginner-friendly and don't go too
13+
deep into advanced topics
14+
315
## Writing documentation
416

17+
!!! tip inline end
18+
For simple changes you can straight-up just use the edit link available on
19+
every documentation page. It's the pen-icon to the right of the top
20+
heading. Write your changes, preview everything looks as expected and
21+
submit as proposed changes.
22+
523
Documentation is is written as markdown, processed using mkdocs ([docs](https://www.mkdocs.org/user-guide/writing-your-docs/#writing-your-docs)) and the Material theme ([docs](https://squidfunk.github.io/mkdocs-material/reference/)). The Material theme is not just styling, but provides additional syntax extensions.
624

725
Setup your system for mkdocs and Material:
@@ -34,6 +52,47 @@ Services will grow over time, we may split up the buildstack menu into subsectio
3452
* Any configs that are required before getting the service running should be configured in the service's options menu (and a BuildStack menu Issue should be displayed if not).
3553
* Fork the repo and push the changes to your fork. Create a cross repo PR for the mods to review. We may request additional changes from you.
3654

55+
## Commit message
56+
57+
```
58+
service_name: Add/Fix/Change feature or bug summary
59+
60+
Optional longer description of the commit. What is changed and why it
61+
is changed. Wrap at 72 characters.
62+
63+
* You can use markdown formating as this will automatically be the
64+
description of your pull-request.
65+
* End by adding any issues this commit fixes, one per line:
66+
67+
Fixes #1234
68+
Fixes #4567
69+
```
70+
71+
1. The first line is a short description. Keep it short, aim for 50
72+
characters. This is like the subject of an email. It shouldn't try to fully
73+
or uniquely describe what the commit does. More importantly it should aim
74+
to inform *why* this commit was made.
75+
76+
`service_name` - service or project-part being changed, e.g. influxdb,
77+
grafana, docs. Documentation changes should use the the name of the
78+
service. Use `docs` if it's changes to general documentation. If all else
79+
fails, use the folder-name of the file you are changing. Use lowercase.
80+
81+
`Add/Fix/Change` - what type of an change this commit is. Capitalized.
82+
83+
`feature or bug summary` - free very short text giving an idea of why/what.
84+
85+
2. Empty line.
86+
87+
3. A longer description of what and why. Wrapped to 72 characters.
88+
89+
Use [github issue linking](
90+
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
91+
to automatically close issues when the pull-request of this commit is
92+
merged.
93+
94+
For tips on how to use git, see [Git Setup](Git-Setup.md).
95+
3796
## Follow up
3897
If your new service is approved and merged then congratulations! Please watch the Issues page on github over the next few days and weeks to see if any users have questions or issues with your new service.
3998

0 commit comments

Comments
 (0)