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)
|
||||
|
||||
**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)
|
||||
* `armhf` for ARMv7 devices 32 Bit (e.g. most Raspberry Pi 1/2/3/4)
|
||||
* `arm64` for ARMv8 devices 64 Bit (not Raspberry Pi 3/4)
|
||||
* `linux/amd64`
|
||||
* `linux/arm64`
|
||||
* `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
|
||||
|
||||
|
|
@ -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:
|
||||
|
||||
* `docker ps` - lists all your currently running container
|
||||
* `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)
|
||||
`docker exec -it openhab /openhab/runtime/bin/client`
|
||||
|
||||
The default password for the login is `habopen`.
|
||||
The default password for the login is: `habopen`
|
||||
|
||||
### Startup modes
|
||||
|
||||
|
|
@ -452,14 +448,14 @@ All messages shown during the update are also logged to `userdata/logs/update.lo
|
|||
|
||||
## 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
|
||||
$ docker build --tag 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:
|
||||
|
||||
|
|
@ -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.
|
||||
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
|
||||
|
||||
|
|
@ -500,78 +496,6 @@ and add a volume mount to your startup:
|
|||
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.
|
||||
|
||||
### 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
|
||||
|
||||
### 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