Skip to content

Commit

Permalink
Merge pull request #509 from ukkopahis/doc-improvements
Browse files Browse the repository at this point in the history
docs: contribution guidelines, update overview, git setup and usage, syntax&usability fixes, freeze mkdocs requirements, sudo nopasswd
  • Loading branch information
Slyke authored Apr 26, 2022
2 parents d840775 + e1dcd3e commit 732889a
Show file tree
Hide file tree
Showing 10 changed files with 406 additions and 20 deletions.
4 changes: 3 additions & 1 deletion docs/Basic_setup/Networking.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,9 @@ An easy way to find out your IP is by typing `ip address` in the terminal and lo

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

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

## Examples
- 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`
Expand All @@ -25,4 +27,4 @@ For adminer:
ports:
- 9080:8080
```
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
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
18 changes: 9 additions & 9 deletions docs/Basic_setup/Understanding-Containers.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ In simple terms, Docker is a software platform that simplifies the process of bu
managing and distributing applications. It does this by virtualizing the operating system of the
computer on which it is installed and running.

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

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

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

# Docker Terminology
## Docker Terminology

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

# What is Docker-Compose?
## What is Docker-Compose?

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

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

# How Docker Compose Works?
## How Docker Compose Works?

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

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

# How the container are connected to host machine
## How the container are connected to host machine

## Volumes
### Volumes

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

## Ports
### Ports
When containers running a we would like to delegate some services to the outside world, for example
OpenHAB web frontend have to be accessible for users. There are several ways to achive that. One is
mounting the port to the most machine, this called port binding. On that case service will have a dedicated
Expand Down
12 changes: 12 additions & 0 deletions docs/Basic_setup/What-is-sudo.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,3 +45,15 @@ Please try to minimise your use of `sudo` when you are working with IOTstack. He
```

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!

## Configuration

To edit sudo functionality and permissions use: `sudo visudo`

For instance, to allow sudo usage without prompting for a password:
```bash
# Allow members of group sudo to execute any command without password prompt
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
```

For more information: `man sudoers`
178 changes: 178 additions & 0 deletions docs/Developers/Git-Setup.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,178 @@
How to setup and use git for IOTstack development.

1. First, create a
[fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) of
SensorsIot/IOTstack on github. And
[setup](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
your ssh-keys.
1. Clone your fork and setup your github username and email
``` console
$ git clone [email protected]:<username>/IOTstack.git
$ cd IOTstack
$ git config user.name <username>
$ git config user.email <1234>+<username>@users.noreply.github.com
```
1. Add up the SensorsIot/IOTstack upstream
``` console
$ git remote add upstream https://github.com/SensorsIot/IOTstack.git
```
1. Configure for ease of operation
``` console
$ git config fetch.prune true
$ git config remote.pushDefault origin
$ git config --add remote.origin.fetch "^refs/heads/gh-pages"
$ git config --add remote.upstream.fetch "^refs/heads/gh-pages"
$ git config branch.master.mergeoptions "--no-ff"
$ git config fetch.parallel 0
$ git fetch --all
```

## Make a pull-request

``` mermaid
flowchart LR
upstream["upstream (SensorsIOT)"] -- "1. git fetch + git checkout -b"
--> local[local branch]
local -- "2. git commit" --> local
local -- "3. git push" --> origin["origin (your fork)"]
origin -- "3. create github pull-request" --> upstream
```

Please see [Contributing](index.md) for instructions on how to write commit
messages.

``` console
$ git fetch upstream
$ git checkout -b <your-descriptive-branch-name> upstream/master
...coding and testing...
$ git add <your new or changed file>
Check everything has been added:
$ git status
$ git commit
$ git push
```
When you execute git push, its output should have a link for creating the
pull-request to github.

## Common operations

### Show compact history with "git lg"

``` console
$ 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"
```

### Remove branches of merged pull-requests.

When your pull-requests have been merged, their branches aren't needed anymore.
Remove them to reduce clutter and distractions. The master branch is never
deleted.

``` console
$ git fetch --all
$ git checkout master
$ git branch -r --merged upstream/master | \
grep -v origin/master$ | grep origin | sed 's/origin\///' | \
xargs -I 'B' git push --delete origin B
$ git branch --merged upstream/master | grep -v " master$" | \
xargs -I'B' git branch -d B
```

## Advanced topics

### Fetch all pull-requests as branches

This is handy for easily testing out other persons' suggested changes. The
branches are of course fetch-only, and you can't push your own commits to them.

``` console
$ git config --add remote.upstream.fetch +refs/pull/*/head:refs/remotes/upstream/pr-*
$ git fetch upstream
```

*Note:* Everything below requires this.

### Show up-to-date branches not merged

Branches that include the latest upstream/master, but are not merged to
your current branch, are potentially mergeable pull-requests. This is useful
for identifying which pull-requests you should be able to merge without
conflict.

``` console
$ git fetch upstream
$ git branch -r --contains upstream/master --no-merged upstream/master
```

### Check pull-requests on Github can be merged without conflicts

In git, the only way to know if a branch can be merged without a conflict, is
by actually doing the merge. An alias to (re-)create a branch named
`merge-test` and do merges into it:

``` console
$ git config alias.test-pull-request-merge $'!f() { : git merge && \
OPENPULLS=$(curl -s \'https://api.github.com/repos/SensorsIot/IOTstack/pulls?base=master&per_page=100\' | \
grep "^.....number" | sed -E \'s/.* ([0-9]+),/ upstream\\/pr-\\1/\') && \
git fetch upstream && git checkout -B merge-test upstream/master && \
git branch -r --contains upstream/master --no-merged upstream/master | \
grep upstream/pr- | sort - <(echo "$OPENPULLS") | \
{ uniq -d; [[ "$1" ]] && echo "$1"; } | \
xargs -I B sh -c "echo Merging B && \
git merge --no-rerere-autoupdate --no-ff --quiet B || \
{ echo ***FAILED TO MERGE B && exit 255; };" ;}; f'
```

<!-- Old version using 'plain' commands
``` console
$ OPENPULLS=$(curl -s 'https://api.github.com/repos/SensorsIot/IOTstack/pulls?state=open&per_page=100' | \
grep "^.....number" | sed -E 's/.* ([0-9]+),/ upstream\/pr-\1/')
$ git fetch upstream && git checkout -B merge-test upstream/master && \
git branch -r --contains upstream/master --no-merged upstream/master | \
grep upstream/pr- | sort - <(echo "$OPENPULLS") | uniq -d | \
xargs -I B sh -c "echo Merging B && \
git merge --no-rerere-autoupdate --no-ff --quiet B || \
( echo ***FAILED TO MERGE B && exit 255 )"
```
-->


Then use this alias combined with `git checkout -`, returning your working copy
back to the original branch if all merges succeeded:

``` console
$ git test-pull-request-merge && git checkout -
```

This merges all branches that are: a) currently open pull requests and b)
up-to-date, i.e. contains upstream/master and c) not merged already and d) the
optional provided argument. Note: won't ignore draft pull-requests. If it
encounters a failure, it stops immediately to let you inspect the conflict.

!!! help "Failed merge?"

*If* there was a merge-conflict, inspect it e.g. using `git diff`, but
don't do any real work or conflict resolution in the merge-test branch.
When you have understood the merge-conflict and want to leave the
merge-test branch, abort the failed merge and switch to your actual branch:

``` console
$ git diff
$ git merge --abort
$ git checkout <your-PR-branch-that-resulted-in-the-conflict>
```

### Check your branch doesn't conflict with any existing pull-request

When you intend to submit a pull-request you might want to check that it won't
conflict with any of the existing pull-requests.

1. Commit all your changes into your pull request branch.
2. Use the alias from the previous "Test all current pull-requests..."-topic
to test merging your branch in addition to all current pull request:

``` console
$ git test-pull-request-merge <your-pull-request-branch> && git checkout -
```

If there is a merge-conflict, see "Failed merge?" above.
59 changes: 59 additions & 0 deletions docs/Developers/index.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,25 @@
# Contributing

We welcome pull-requests.

For larger contributions, please open an issue describing your idea. It
may provide valuable discussion and feedback. It also prevents the unfortunate
case of two persons working on the same thing. There's no need to wait for any
approval.

!!! check "Development guidelines"
* It-just-works - use good defaults that will work well for a first time user
* Keep-it-simple - try to keep stuff beginner-friendly and don't go too
deep into advanced topics

## Writing documentation

!!! tip inline end
For simple changes you can straight-up just use the edit link available on
every documentation page. It's the pen-icon to the right of the top
heading. Write your changes, preview everything looks as expected and
submit as proposed changes.

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.

Setup your system for mkdocs and Material:
Expand Down Expand Up @@ -34,6 +52,47 @@ Services will grow over time, we may split up the buildstack menu into subsectio
* 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).
* 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.

## Commit message

```
service_name: Add/Fix/Change feature or bug summary
Optional longer description of the commit. What is changed and why it
is changed. Wrap at 72 characters.
* You can use markdown formating as this will automatically be the
description of your pull-request.
* End by adding any issues this commit fixes, one per line:
Fixes #1234
Fixes #4567
```

1. The first line is a short description. Keep it short, aim for 50
characters. This is like the subject of an email. It shouldn't try to fully
or uniquely describe what the commit does. More importantly it should aim
to inform *why* this commit was made.

`service_name` - service or project-part being changed, e.g. influxdb,
grafana, docs. Documentation changes should use the the name of the
service. Use `docs` if it's changes to general documentation. If all else
fails, use the folder-name of the file you are changing. Use lowercase.

`Add/Fix/Change` - what type of an change this commit is. Capitalized.

`feature or bug summary` - free very short text giving an idea of why/what.

2. Empty line.

3. A longer description of what and why. Wrapped to 72 characters.

Use [github issue linking](
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
to automatically close issues when the pull-request of this commit is
merged.

For tips on how to use git, see [Git Setup](Git-Setup.md).

## Follow up
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.

Expand Down
Loading

0 comments on commit 732889a

Please sign in to comment.