Java Runtime Environment: 11.0.15 (Temurin-11.0.15+10) (running in Docker)
openHAB version: 3.4.4 (running in Docker)
ConBee 2 USB stick
I’ve built this little service to create screenshots from an openHAB dashboard. Since the service also handles authenticating against openHAB (logging in), I want to test this particular feature in a system integration test (SIT, e. g. to easily verify that my code is still working with a new release of either openHAB or the used technology stack .NET as part of the automated build process) and for this I need an easily runnable openHAB instance.
The public demo openHAB has all I need - except the login. That’s why I was thinking that if the public demo is based on a Docker image, I could use it, make the temperature dashboard only accessible to a user and persist this as a new Docker image that I can use for my SIT.
Of course, I could also use the pure openHAB Docker image and create the dashboard, user, etc. on my own, but since I’d have to do this for each and every openHAB release, I’m looking for a way to either automate this process or use already existing resources.
Not really. You’d just need to update the config on those rare cases where the config cannot be updated automatically which is almost always only going to be when there’s a major version number change (e.g. 3.4 to 4.0). Within a given version number, any required changes to the config are handled automatically. Even then there are almost never any of these changes because that usually means a breaking change which are not allowed except at a major version change.
But ultimately, if that’s not sufficient, someone is going to have to create and keep up these Docker images. Since you are the one who needs this feature, it’s most likely to be implemented if you do so and submit the PR than otherwise. I can’t imagine someone else volunteering to do this as it’s a pretty niche use case.
That’s very interesting, I didn’t know that. So basically I could spawn a Docker container from the official base image, copy the config into it (maybe restart?) and that’s it? That would be perfect for my needs
But what I don’t see in the config you mentioned is the temperature dashboard
I’d swap the order. Clone the config and spawn a container with that config mounted.
You could get even more clever. The first thing that the container does is execute scripts mounted into it under init.d (see the openHAB image docs for details). You could in that init script clone the demo configs into the container before OH comes up.
But even if you do it all outside the container, if you clone the config first there’s no need to restart the container.
I’m not 100% now that that is the config in question. The MainUI config will be under userdata but there isn’t a josndb folder there checked in so maybe that isn’t the source of the demo config.