Cleanup repo and README.md (#334)
* Remove unused files and duplicated content * Remove contrib file content from README.md to prevent reaching Docker Hub 25K limit * Reference Docker platforms instead of architectures * Add CODEOWNERS file Signed-off-by: Wouter Born <github@maindrain.net>pull/335/head
Wouter Born
GitHub
parent
61f4582920
commit
a3aabf1853
25
AUTHORS
25
AUTHORS
|
|
@ -1,25 +0,0 @@
|
||||||
# This file lists all individuals having contributed content to the repository.
|
|
||||||
# For how it is generated, see `project-orga/generate-authors.sh`.
|
|
||||||
|
|
||||||
axxelG <axxelG@users.noreply.github.com>
|
|
||||||
Björn Dieding <xrow@users.noreply.github.com>
|
|
||||||
Chill3x <alex.freidel@gmail.com>
|
|
||||||
Christian 'Pelle' Pelster <pelle@pelle.io>
|
|
||||||
Christian Häussler <c-n-i@web.de>
|
|
||||||
daaaaaaaan <dancaws@gmail.com>
|
|
||||||
Dominik Krickl-Vorreiter <dominikkv@gmx.de>
|
|
||||||
Florian <florian.schmidt.welzow@t-online.de>
|
|
||||||
Hannes Schaller <admin@cyberkov.at>
|
|
||||||
Hans van den Bogert <hansbogert@gmail.com>
|
|
||||||
Kai Kreuzer <kai@openhab.org>
|
|
||||||
legacycode <christian_lehmann@gmx.de>
|
|
||||||
Mariano Gonzalez <eschizoid@hotmail.com>
|
|
||||||
Martin van Wingerden <martinvw@users.noreply.github.com>
|
|
||||||
mezz64 <mezz@johnmihalic.com>
|
|
||||||
Michael R Carroll <me@michaelrcarroll.com>
|
|
||||||
Pascal Gollor <kalle@pgollor.de>
|
|
||||||
Richard Koshak <rkoshak@users.noreply.github.com>
|
|
||||||
Simon Merschjohann <smerschjohann@users.noreply.github.com>
|
|
||||||
The Gitter Badger <badger@gitter.im>
|
|
||||||
Tim Sedlmeyer <sedlmeyer@gmail.com>
|
|
||||||
Wouter Born <github@maindrain.net>
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
# This file helps GitHub doing automatic review requests for new PRs.
|
||||||
|
# It should always list the active Docker maintainers.
|
||||||
|
|
||||||
|
# Assign all PRs to the Docker maintainers:
|
||||||
|
* @openhab/docker-maintainers
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Christian Häussler <c-n-i@web.de> (@cniweb)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
openHAB - a vendor and technology agnostic open source automation software for your home.
|
|
||||||
98
README.md
98
README.md
|
|
@ -89,15 +89,15 @@ If you are unsure about what your needs are, you probably want to use `openhab/o
|
||||||
|
|
||||||
Prebuilt Docker Images can be found here: [Docker Images](https://hub.docker.com/r/openhab/openhab)
|
Prebuilt Docker Images can be found here: [Docker Images](https://hub.docker.com/r/openhab/openhab)
|
||||||
|
|
||||||
**Architectures:**
|
**Platforms:**
|
||||||
|
|
||||||
The following architectures are supported (automatically determined):
|
The following Docker platforms are supported (automatically determined):
|
||||||
|
|
||||||
* `amd64` for most desktop computers (e.g. x64, x86-64, x86_64)
|
* `linux/amd64`
|
||||||
* `armhf` for ARMv7 devices 32 Bit (e.g. most Raspberry Pi 1/2/3/4)
|
* `linux/arm64`
|
||||||
* `arm64` for ARMv8 devices 64 Bit (not Raspberry Pi 3/4)
|
* `linux/arm/v7`
|
||||||
|
|
||||||
There is no armhf Alpine image for openHAB 3 because the openjdk11 package is unavailable for this architecture.
|
There is no `linux/arm/v7` Alpine image for openHAB 3 because the openjdk11 package is unavailable for this platform.
|
||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
|
|
||||||
|
|
@ -308,13 +308,9 @@ Here is an example playbook in case you control your environment with Ansible. Y
|
||||||
|
|
||||||
You can connect to a console of an already running openHAB container with following command:
|
You can connect to a console of an already running openHAB container with following command:
|
||||||
|
|
||||||
* `docker ps` - lists all your currently running container
|
`docker exec -it openhab /openhab/runtime/bin/client`
|
||||||
* `docker exec -it openhab /openhab/runtime/bin/client` - connect to openHAB container by name
|
|
||||||
* `docker exec -it openhab /openhab/runtime/bin/client -p habopen` - connect to openHAB container by name and use `habopen` as password (**not recommended** because this makes the password visible in the command history and process list)
|
|
||||||
* `docker exec -it c4ad98f24423 /openhab/runtime/bin/client` - connect to openHAB container by id
|
|
||||||
* `docker attach openhab` - attach to openHAB container by name, input only works when starting the container with `-it` (or `stdin_open: true` and `tty: true` with Docker Compose)
|
|
||||||
|
|
||||||
The default password for the login is `habopen`.
|
The default password for the login is: `habopen`
|
||||||
|
|
||||||
### Startup modes
|
### Startup modes
|
||||||
|
|
||||||
|
|
@ -452,14 +448,14 @@ All messages shown during the update are also logged to `userdata/logs/update.lo
|
||||||
|
|
||||||
## Building the images
|
## Building the images
|
||||||
|
|
||||||
Checkout the GitHub repository, change to a directory containing a Dockerfile (e.g. `3.0.0/debian`) and then run these commands to build and run a Docker image for your current architecture:
|
Checkout the GitHub repository, change to a directory containing a Dockerfile (e.g. `3.0.0/debian`) and then run these commands to build and run a Docker image for your current platform:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ docker build --tag openhab/openhab .
|
$ docker build --tag openhab/openhab .
|
||||||
$ docker run openhab/openhab
|
$ docker run openhab/openhab
|
||||||
```
|
```
|
||||||
|
|
||||||
To be able to build the same image for other architectures (e.g. armhf/arm64 on amd64) Docker CE 19.03 with BuildKit support can be used.
|
To be able to build the same image for other platforms (e.g. arm/v7, arm64 on amd64) Docker CE 19.03 with BuildKit support can be used.
|
||||||
|
|
||||||
First enable BuildKit support, configure QEMU binary formats and a builder using:
|
First enable BuildKit support, configure QEMU binary formats and a builder using:
|
||||||
|
|
||||||
|
|
@ -481,7 +477,7 @@ $ docker buildx build --platform linux/arm/v7 --tag openhab/openhab --load .
|
||||||
|
|
||||||
It is sometimes useful to run shell scripts after the "userdata" directory is created, but before Karaf itself is launched.
|
It is sometimes useful to run shell scripts after the "userdata" directory is created, but before Karaf itself is launched.
|
||||||
One such case is creating SSH host keys, and allowing access to the system from the outside via SSH.
|
One such case is creating SSH host keys, and allowing access to the system from the outside via SSH.
|
||||||
Exemplary scripts can be found in the [contrib](https://github.com/openhab/openhab-docker/tree/master/contrib) directory
|
Exemplary scripts can be found in the [contrib/cont-init.d](https://github.com/openhab/openhab-docker/tree/master/contrib/cont-init.d) directory
|
||||||
|
|
||||||
To use this, create a directory called
|
To use this, create a directory called
|
||||||
|
|
||||||
|
|
@ -500,78 +496,6 @@ and add a volume mount to your startup:
|
||||||
and put your scripts into that directory.
|
and put your scripts into that directory.
|
||||||
This can be done by either using a volume mount (see the examples above) or creating your own images which inherit from the official ones.
|
This can be done by either using a volume mount (see the examples above) or creating your own images which inherit from the official ones.
|
||||||
|
|
||||||
### Show the contents of the running Docker image
|
|
||||||
|
|
||||||
[10-show-directories](https://github.com/openhab/openhab-docker/blob/master/contrib/cont-init.d/10-show-directories)
|
|
||||||
|
|
||||||
```shell
|
|
||||||
ls -l "${OPENHAB_HOME}"
|
|
||||||
ls -l "${OPENHAB_USERDATA}"
|
|
||||||
```
|
|
||||||
|
|
||||||
### Set a defined host key for the image
|
|
||||||
|
|
||||||
[20-set-host-key](https://github.com/openhab/openhab-docker/blob/master/contrib/cont-init.d/20-set-host-key)
|
|
||||||
|
|
||||||
```shell
|
|
||||||
cat > "${OPENHAB_USERDATA}/etc/host.key" <<EOF
|
|
||||||
-----BEGIN PRIVATE KEY-----
|
|
||||||
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQCrOe8O7r9uOjKu
|
|
||||||
... your key here ...
|
|
||||||
c2woMmUlKznoVPczYMncRJ3oBg==
|
|
||||||
-----END PRIVATE KEY-----
|
|
||||||
EOF
|
|
||||||
```
|
|
||||||
|
|
||||||
### Open access from external hosts
|
|
||||||
|
|
||||||
[20-open-ssh-server](https://github.com/openhab/openhab-docker/blob/master/contrib/cont-init.d/20-open-ssh-server)
|
|
||||||
|
|
||||||
```shell
|
|
||||||
sed -i \
|
|
||||||
"s/\#org.apache.karaf.shell:sshHost\s*=.*/org.apache.karaf.shell:sshHost=0.0.0.0/g" \
|
|
||||||
"${OPENHAB_CONF}/services/runtime.cfg"
|
|
||||||
```
|
|
||||||
|
|
||||||
### Set a defined host key for the image
|
|
||||||
|
|
||||||
[20-add-allowed-ssh-keys](https://github.com/openhab/openhab-docker/blob/master/contrib/cont-init.d/20-add-allowed-ssh-keys)
|
|
||||||
|
|
||||||
```shell
|
|
||||||
cat > "${OPENHAB_USERDATA}/etc/keys.properties" <<EOF
|
|
||||||
openhab=A...your-ssh-public-key-here...B,_g_:admingroup
|
|
||||||
|
|
||||||
_g_\:admingroup = group,admin,manager,viewer
|
|
||||||
|
|
||||||
EOF
|
|
||||||
```
|
|
||||||
|
|
||||||
### Configure credentials for openHAB cloud
|
|
||||||
|
|
||||||
[40-openhabcloud](https://github.com/openhab/openhab-docker/blob/master/contrib/cont-init.d/40-openhabcloud)
|
|
||||||
|
|
||||||
```shell
|
|
||||||
if [ ! -z ${OHC_UUID} ]
|
|
||||||
then
|
|
||||||
mkdir -p "${OPENHAB_USERDATA}"
|
|
||||||
echo ${OHC_UUID} > "${OPENHAB_USERDATA}/uuid"
|
|
||||||
fi
|
|
||||||
|
|
||||||
if [ ! -z ${OHC_SECRET} ]
|
|
||||||
then
|
|
||||||
mkdir -p "${OPENHAB_USERDATA}/openhabcloud"
|
|
||||||
echo ${OHC_SECRET} > "${OPENHAB_USERDATA}/openhabcloud/secret"
|
|
||||||
fi
|
|
||||||
```
|
|
||||||
|
|
||||||
### Give pcap permissions to the Java process
|
|
||||||
|
|
||||||
[50-setpcap-on-java](https://github.com/openhab/openhab-docker/blob/master/contrib/cont-init.d/50-setpcap-on-java)
|
|
||||||
|
|
||||||
```shell
|
|
||||||
setcap 'cap_net_bind_service=+ep' "${JAVA_HOME}/bin/java"
|
|
||||||
```
|
|
||||||
|
|
||||||
## Common problems
|
## Common problems
|
||||||
|
|
||||||
### Error: KARAF_ETC is not valid
|
### Error: KARAF_ETC is not valid
|
||||||
|
|
|
||||||
|
|
@ -1,148 +0,0 @@
|
||||||
# The openHAB Maintainer manual
|
|
||||||
|
|
||||||
## Introduction
|
|
||||||
|
|
||||||
Dear maintainer. Thank you for investing the time and energy to help
|
|
||||||
make openHAB as useful as possible. Maintaining a project is difficult,
|
|
||||||
sometimes unrewarding work. Sure, you will get to contribute cool
|
|
||||||
features to the project. But most of your time will be spent reviewing,
|
|
||||||
cleaning up, documenting, answering questions, and justifying design
|
|
||||||
decisions - while everyone has all the fun! But remember - the quality
|
|
||||||
of the maintainers' work is what distinguishes the good projects from
|
|
||||||
the great. So please be proud of your work, even the unglamourous parts,
|
|
||||||
and encourage a culture of appreciation and respect for *every* aspect
|
|
||||||
of improving the project - not just the hot new features.
|
|
||||||
|
|
||||||
This document is a manual for maintainers old and new. It explains what
|
|
||||||
is expected of maintainers, how they should work, and what tools are
|
|
||||||
available to them.
|
|
||||||
|
|
||||||
This is a living document - if you see something out of date or missing,
|
|
||||||
speak up!
|
|
||||||
|
|
||||||
## What is a maintainer's responsibility?
|
|
||||||
|
|
||||||
It is every maintainer's responsibility to:
|
|
||||||
|
|
||||||
1. Expose a clear road map for improving their component.
|
|
||||||
2. Deliver prompt feedback and decisions on pull requests.
|
|
||||||
3. Be available to anyone with questions, bug reports, criticism etc.
|
|
||||||
on their component. This includes GitHub requests and the mailing
|
|
||||||
list.
|
|
||||||
4. Make sure their component respects the philosophy, design and
|
|
||||||
road map of the project.
|
|
||||||
|
|
||||||
## How are decisions made?
|
|
||||||
|
|
||||||
Short answer: with pull requests to the openHAB-docker repository.
|
|
||||||
|
|
||||||
openHAB is an open-source project with an open design philosophy. This
|
|
||||||
means that the repository is the source of truth for EVERY aspect of the
|
|
||||||
project, including its philosophy, design, road map, and APIs. *If it's
|
|
||||||
part of the project, it's in the repo. If it's in the repo, it's part of
|
|
||||||
the project.*
|
|
||||||
|
|
||||||
As a result, all decisions can be expressed as changes to the
|
|
||||||
repository. An implementation change is a change to the source code. An
|
|
||||||
API change is a change to the API specification. A philosophy change is
|
|
||||||
a change to the philosophy manifesto, and so on.
|
|
||||||
|
|
||||||
All decisions affecting openHAB, big and small, follow the same 3 steps:
|
|
||||||
|
|
||||||
* Step 1: Open a pull request. Anyone can do this.
|
|
||||||
|
|
||||||
* Step 2: Discuss the pull request. Anyone can do this.
|
|
||||||
|
|
||||||
* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
|
|
||||||
this (see below "Who decides what?")
|
|
||||||
+ Accepting pull requests
|
|
||||||
- If the pull request appears to be ready to merge, give it a `LGTM`, which
|
|
||||||
stands for "Looks Good To Me".
|
|
||||||
- If the pull request has some small problems that need to be changed, make
|
|
||||||
a comment addressing the issues.
|
|
||||||
- If the changes needed to a PR are small, you can add a "LGTM once the
|
|
||||||
following comments are addressed..." this will reduce needless back and
|
|
||||||
forth.
|
|
||||||
- If the PR only needs a few changes before being merged, any MAINTAINER can
|
|
||||||
make a replacement PR that incorporates the existing commits and fixes the
|
|
||||||
problems before a fast track merge.
|
|
||||||
+ Closing pull requests
|
|
||||||
- If a PR appears to be abandoned, after having attempted to contact the
|
|
||||||
original contributor, then a replacement PR may be made. Once the
|
|
||||||
replacement PR is made, any contributor may close the original one.
|
|
||||||
- If you are not sure if the pull request implements a good feature or you
|
|
||||||
do not understand the purpose of the PR, ask the contributor to provide
|
|
||||||
more documentation. If the contributor is not able to adequately explain
|
|
||||||
the purpose of the PR, the PR may be closed by any MAINTAINER.
|
|
||||||
- If a MAINTAINER feels that the pull request is sufficiently architecturally
|
|
||||||
flawed, or if the pull request needs significantly more design discussion
|
|
||||||
before being considered, the MAINTAINER should close the pull request with
|
|
||||||
a short explanation of what discussion still needs to be had. It is
|
|
||||||
important not to leave such pull requests open, as this will waste both the
|
|
||||||
MAINTAINER's time and the contributor's time. It is not good to string a
|
|
||||||
contributor on for weeks or months, having them make many changes to a PR
|
|
||||||
that will eventually be rejected.
|
|
||||||
|
|
||||||
## Who decides what?
|
|
||||||
|
|
||||||
All decisions are pull requests, and the relevant maintainers make
|
|
||||||
decisions by accepting or refusing pull requests. Review and acceptance
|
|
||||||
by anyone is denoted by adding a comment in the pull request: `LGTM`.
|
|
||||||
However, only currently listed `MAINTAINERS` are counted towards the
|
|
||||||
required majority.
|
|
||||||
|
|
||||||
openHAB follows the timeless, highly efficient and totally unfair system
|
|
||||||
known as [Benevolent dictator for
|
|
||||||
life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with
|
|
||||||
yours truly, Kai Kreuzer, in the role of BDFL. This means that all
|
|
||||||
decisions are made, by default, by Kai. Since making every decision
|
|
||||||
myself would be highly un-scalable, in practice decisions are spread
|
|
||||||
across multiple maintainers.
|
|
||||||
|
|
||||||
The relevant maintainers for a pull request can be worked out in 2 steps:
|
|
||||||
|
|
||||||
* Step 1: Determine the subdirectories affected by the pull request. This
|
|
||||||
might be `addons/binding/org.openhab.binding.sonos`,
|
|
||||||
`docs/source/installation`, or any other part of the repo.
|
|
||||||
|
|
||||||
* Step 2: Find the `MAINTAINERS` file which affects this directory. If the
|
|
||||||
directory itself does not have a `MAINTAINERS` file, work your way up
|
|
||||||
the repo hierarchy until you find one.
|
|
||||||
|
|
||||||
There is also a `project-prga/getmaintainers.sh` script that will print out the
|
|
||||||
maintainers for a specified directory.
|
|
||||||
|
|
||||||
### I'm a maintainer, and I'm going on holiday
|
|
||||||
|
|
||||||
Please let your co-maintainers and other contributors know by raising a pull
|
|
||||||
request that comments out your `MAINTAINERS` file entry using a `#`.
|
|
||||||
|
|
||||||
### I'm a maintainer. Should I make pull requests too?
|
|
||||||
|
|
||||||
Yes. Nobody should ever push to master directly. All changes should be
|
|
||||||
made through a pull request.
|
|
||||||
|
|
||||||
### Helping contributors with the DCO
|
|
||||||
|
|
||||||
The [DCO or `Sign your work`](
|
|
||||||
https://github.com/openhab/openhab-docker/blob/master/CONTRIBUTING.md#sign-your-work)
|
|
||||||
requirement is not intended as a roadblock or speed bump.
|
|
||||||
|
|
||||||
Some openHAB contributors are not as familiar with `git`, or have used a web based
|
|
||||||
editor, and thus asking them to `git commit --amend -s` is not the best way forward.
|
|
||||||
|
|
||||||
In this case, maintainers can update the commits based on clause (c) of the DCO. The
|
|
||||||
most trivial way for a contributor to allow the maintainer to do this, is to add
|
|
||||||
a DCO signature in a Pull Requests's comment, or a maintainer can simply note that
|
|
||||||
the change is sufficiently trivial that it does not substantivly change the existing
|
|
||||||
contribution - i.e., a spelling change.
|
|
||||||
|
|
||||||
When you add someone's DCO, please also add your own to keep a log.
|
|
||||||
|
|
||||||
### Who assigns maintainers?
|
|
||||||
|
|
||||||
Kai has final `LGTM` approval for all pull requests to `MAINTAINERS` files.
|
|
||||||
|
|
||||||
### How is this process changed?
|
|
||||||
|
|
||||||
Just like everything else: by making a pull request :)
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
#!/bin/sh
|
|
||||||
|
|
||||||
find $1 -name MAINTAINERS -exec cat {} ';' | sed -E -e 's/^[^:]*: *(.*)$/\1/' | grep -E -v -e '^ *$' -e '^ *#.*$' | sort -u
|
|
||||||
|
|
@ -1,15 +0,0 @@
|
||||||
#!/bin/bash
|
|
||||||
set -e
|
|
||||||
|
|
||||||
cd "$(dirname "$(readlink "$BASH_SOURCE")")/.."
|
|
||||||
|
|
||||||
# see also ".mailmap" for how email addresses and names are deduplicated
|
|
||||||
|
|
||||||
{
|
|
||||||
cat <<-'EOH'
|
|
||||||
# This file lists all individuals having contributed content to the repository.
|
|
||||||
# For how it is generated, see `project-orga/generate-authors.sh`.
|
|
||||||
EOH
|
|
||||||
echo
|
|
||||||
git log --format='%aN <%aE>' | sort -uf
|
|
||||||
} > AUTHORS
|
|
||||||
|
|
@ -1,62 +0,0 @@
|
||||||
#!/usr/bin/env bash
|
|
||||||
set -e
|
|
||||||
|
|
||||||
if [ $# -ne 1 ]; then
|
|
||||||
echo >&2 "Usage: $0 PATH"
|
|
||||||
echo >&2 "Show the primary and secondary maintainers for a given path"
|
|
||||||
exit 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
set -e
|
|
||||||
|
|
||||||
DEST=$1
|
|
||||||
DESTFILE=""
|
|
||||||
if [ ! -d $DEST ]; then
|
|
||||||
DESTFILE=$(basename $DEST)
|
|
||||||
DEST=$(dirname $DEST)
|
|
||||||
fi
|
|
||||||
|
|
||||||
MAINTAINERS=()
|
|
||||||
cd $DEST
|
|
||||||
while true; do
|
|
||||||
if [ -e ./MAINTAINERS ]; then
|
|
||||||
{
|
|
||||||
while read -r line; do
|
|
||||||
re='^([^:]*): *(.*)$'
|
|
||||||
file=$(echo $line | sed -E -n "s/$re/\1/p")
|
|
||||||
if [ ! -z "$file" ]; then
|
|
||||||
if [ "$file" = "$DESTFILE" ]; then
|
|
||||||
echo "Override: $line"
|
|
||||||
maintainer=$(echo $line | sed -E -n "s/$re/\2/p")
|
|
||||||
MAINTAINERS=("$maintainer" "${MAINTAINERS[@]}")
|
|
||||||
fi
|
|
||||||
else
|
|
||||||
MAINTAINERS+=("$line");
|
|
||||||
fi
|
|
||||||
done;
|
|
||||||
} < MAINTAINERS
|
|
||||||
break
|
|
||||||
fi
|
|
||||||
if [ -d .git ]; then
|
|
||||||
break
|
|
||||||
fi
|
|
||||||
if [ "$(pwd)" = "/" ]; then
|
|
||||||
break
|
|
||||||
fi
|
|
||||||
cd ..
|
|
||||||
done
|
|
||||||
|
|
||||||
PRIMARY="${MAINTAINERS[0]}"
|
|
||||||
#PRIMARY_FIRSTNAME=$(echo $PRIMARY | cut -d' ' -f1)
|
|
||||||
LGTM_COUNT=${#MAINTAINERS[@]}
|
|
||||||
LGTM_COUNT=$((LGTM_COUNT%2 +1))
|
|
||||||
|
|
||||||
firstname() {
|
|
||||||
echo $1 | cut -d' ' -f1
|
|
||||||
}
|
|
||||||
|
|
||||||
echo "A pull request in $1 will need $LGTM_COUNT LGTM's to be merged."
|
|
||||||
echo "--- $PRIMARY is the PRIMARY MAINTAINER of $1."
|
|
||||||
for SECONDARY in "${MAINTAINERS[@]:1}"; do
|
|
||||||
echo "--- $SECONDARY"
|
|
||||||
done
|
|
||||||
Loading…
Reference in New Issue