I was not adding this to the default installation routine called by openhabian-setup.sh. I'm not sure if this should be included in the default setup or not?

We'll review first then when done decide on this.

For now I was not creating any test files du to my inexperience. I defeinitely need some information where test files are needed and how to make them.

We want you to provide BATS test cases for all major functions but as you're not really providing the functionality itself (but just the interface on top) I'd say in the first place all we need is a test case that installs your extension and does some basic verification it is working properly. This could run e.g. a web request to install (but not run) a specific OH version.
It's not that hard to write such a test case. Check out *.bats in the openhabian repo for examples.
You can install BATS locally for your testing run purposes. Once we should merge your code it'll be run on every build on a docker machine in the Github cloud.

@mstormi thanks for the feedback. I was able to create a bats file. Unfortunately I can’t run a full test. First I wrote a bats file which made some web calls to ensure that the services are up and responding. But this is not possible inside the docker container. The problem is caused by the cockpit service. This can not start inside the docker due to the following error:

# ERROR:systemctl: cockpit.service: Exec is not an absolute path:  ExecStartPre=+/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=
# ERROR:systemctl: cockpit.service: Exec command does not exist: (ExecStartPre) +/usr/sbin/remotectl
# ERROR:systemctl: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# ERROR:systemctl: The SystemD ExecXY commands must always be absolute paths by definition.
# ERROR:systemctl: Oops, 1 executable paths were not found in the current environment. Refusing.
# ERROR:systemctl: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# ERROR:systemctl:the ExecStartPre control process exited with error code

I made some research and found out that the cockpit can not run inside a container. If you want this to run as container you can download a special designed container from cockpit-project. But you can run the normal service inside the container. So I think a full functionality test can not be performed.

However I managed to create a bats file which checks if the cockpit.socks and cockpit.service are at least loaded by systemctl (not active). So I can ensure that the apt package installation was successfully. Then I check if the html files in the web folder are all there. And I verify if the scripts that are called by the webservice have the required executable permission.

I'm not happy with this test because I would like to make some wget calls to the webservice but due to the described issue this can not be done on the docker test system. A normal installation with openhabian-cli and also by calling the function directly is possible. I tested this on 3 systems.

Maybe you know this issues from other tests and have some hint how to handle this on tests?

There is some other point I noticed during my tests. If you install the FIND 3 application with openhabian-config it will call a function go_setup(). This function adds the debian backports repository to /etc/apt/sources.list.d/golang.list. I'm using the same repository for cockpit. At the moment I add this under /etc/apt/sources.list.d/backports.list because I was not aware about the go_setup function. This causes warnings for duplicated source entries during apt update. For compatibility reason I would suggest that I also write the repo to /etc/apt/sources.list.d/golang.list but this is somehow confusing because this has nothing to do with go from my perspective.

@mstormi @flo-mic

Another thought on the style of this project, would we want all the cockpit source files here, or in another git repository? That way it could be installed in /opt like other optional components.

Perhaps I am way out on a limb here but just a thought.

@ecdye this is a good question. I'm not sure what would be the best way and I'm totally open for ideas here.

At the beginning I had this in my own repository but as mstormi and also rkoshak mentioned in the community topic it should be included in openhabian.

Just for clarification I only added the openhabian addon for cockpit to this repository. The main application is installed via apt install from debian backports repository in any case so the size of this repo should not grow dramatically ;)

@flo-mic I am sorry to ask this, but can you rebase this on the main branch. We have just switched away from using master and it will only be used for legacy updates.

This can not start inside the docker due to the following error:

Did you run another Docker container or reused any of those openHABian runs at build time ?
They actually have a modified systemctl installed that does not require systemd to run with PID 1.
Check if if works with Cockpit.

@ecdye are you (still) reviewing this ?

FWIW I've just stumbled across the "Blame" feature of GitHub: it's a button at the top when you display a file in a repo and tells you per-line who changed it last i.e. who to blame for it :)

Not really, as I was hoping that @flo-mic would be able to rebase on main because we aren't really making feature changes to OH 2 any more.

FYI Blame has been around for a long time.

Not really, as I was hoping that @flo-mic would be able to rebase on main because we aren't really making feature changes to OH 2 any more.

yes please. @flo-mic do you read ?

@flo-mic sis you notice the request to rebase?

@flo-mic any particular reason you closed this ?