Adding container testing #1085
Adding container testing #1085
Conversation
|
@jens-maus - sorry for the previous noise in the old PR while I was (slowly) working on this. I had to ensure that forks would build and push containers again (in case the secret for upload is present) so I could test on my own. Now it should work for you and forks. Since PRs do not have access to the secret you will not be able to see the regression result until you merge: please check my fork actions to see the result there. Should we have a wiki page or a document in git to describing how to set your dev environment including enabling github actions? I could also contribute a Dockerfile.dev for https://code.visualstudio.com/docs/remote/containers so contributors would have a ready to use container with exportroot and any other build dependencies: see https://developers.home-assistant.io/docs/development_environment/ |
|
|
Thanks @angelnu for this PR. I am, however, not quite sure if a straight integration of this PR is really a good thing ATM. While I like the general idea of extending the CI with automated tests, I am not sure if the general CI workflow is the right place for it. You know that this workflow (and the nightly snapshot one) already takes quite a few hours until it is finished and I am still happy that they don't timeout in the GitHub runners (which have a max 6 hours timeout). Wouldn't it be better to put this additional CI testing in a separate workflow just for this purpose? At least as long as we have nothing more than a simple "it's up and running" test, this should IMHO suffice for the time being. And as soon as we have more automated tests integrated (e.g. device learning, webui testing, rega script testing, etc.) we could then think about moving these tests back to the general "CI" workflow which is run with every push. Or what is your opinion?
Yes, more documentation and especially development documentation is highly appreciated! And as you are the "Docker specialist" here, I would say: Go ahead! I am, btw, especially interested in getting a "RapsberryMatic" homeassitant addon implemented, but simply lacked the time yet to work on that topic. But if we could - now that we have the docker in general - work together on such a homeassistant addon of RaspberryMatic, that would be great! Would you be interested? |
|
you are right that the the CI is already painful long enough... Other CIs I am familiar with allow to trigger a workflow from another so we could split in more managable smaller chunks. I do not know how much GitHub actions has in this regard but I can investigate. My proposal is we keep a quick test that runs on each PR/commit so we know it is not breaking the basics (something that does not add more than 5 minutes) and a long full test testing each latest snapshot during the night. If you agree then I would propose merging and I would add a cronjob workflow skeleton for the full regression in a following CI.
Ok, will add :-) I tend to prefer keeping dev documentation in git (instead of wiki) so it is aligned with the actual code. Ok?
I have experiences writing Home Assistant Core addons but not fo the underlying OS. So which type of addon did you have in mind? Most likely you mind running the new Raspberrymatic OCI in Home Assistant OS, right? |
That's fine with me.
Also good. Potentially you could simply reuse the DEVELOPMENT.md in the top-level dir of the repo and add your information there.
Exactly. My plan/idea is to have a home assistant addon that is similar to the current/limited "HomeMatic OCCU Addon" they have created themselves (https://github.com/home-assistant/addons/tree/master/homematic). And then use this "RaspberryMatic Addon" in their home assistant OS (https://github.com/home-assistant/operating-system) which is also based on buildroot, like RaspberryMatic. There we could then integrate the kernel module loading and hopefully the homeassistant developers accept the PR then... So if you could take care of the first basics for a home assistant addon, this would be great (best would be IMHO to create this addon as another RaspberryMatic "platform" as part of this github project). And I could then prepare the PR for the home assistant operating system. That would be again a great teamwork IMHO :) What do you think? |
|
Good, will add to DEVELOPMENT.md On Home Assistant - I only use the Home Assistant Core as Helm (https://artifacthub.io/packages/helm/k8s-at-home/home-assistant). There I added a couple of features and could propose the Raspberrymatic but IMO there is no advantage compared to deploying in 2 Helm charts. I have no experience with the Home Assistant OS (beyond having deployed to a friend) but I could take a look what it would take. Do you have an issue to document this feature where I can add what I find. |
I understand that there is no real advantage if you can start RaspberryMatic as a docker aside a Home Assistant Docker and just interconnect between them. That's of course not what I am looking for.
Well, the idea is to prepare a PR for the Home Assistant OS (https://github.com/home-assistant/operating-system) proposing an integration of the necessary kernel drivers (eq3_char_loop, raw_uart, hb-rf-usb/hb-rf-eth) and then also work on a "RaspberryMatic Home Assistant Addon" which more or less works like existing "OCCU Addon" (https://github.com/home-assistant/addons/tree/master/homematic) but then use the RaspberryMatic docker image instead of trying to replicate what the OCCU HomeAssistant Addon tries to achieve by doing the same like RaspberryMatic internally does already... |
As I was trying to use the OCCU directly myself I know how hard it to stay current with all you do in Raspberrymatic. So yes, it makes sense and the HA OS is the easiest way to use HA compared to advanced (and complex) K8S. I do not have use of it myself but I want to see the two projects I use improving so I will see if I can prepare the PR. BTW: another area I keep in my backburner to contribute to is the Homematic adapter in HA to adopt the new design (no config files) approach. And maybe get some of Rasoberrymatic features such Dutty-Cycle or signal strength reported to Homematic. EDIT:
|
Indeed! That's why I think it would be great to have the kernel drivers integrated in HA OS and also a RaspberryMatic Addon for it which will then utilize the kernel drivers and start the dockerized RaspberryMatic on HA OS.
That would really be appreciated! 👍
That also sounds great and should be quite easily doable! If possible, I can assist of course.
That sounds't great for a starter. So, ok. I will the merge this PR and see how good it performs. Then I will see if I can work on preparing a PR for integrating the kernel drivers in HA OS while you prepare the template/start for a HA OS Addon integration that starts the dockerized RaspberryMatic as a Addon. |
|
there seems to give some delay between uploading the container until it can be downloaded - if you retry it works. We would need to add some delay I expect |
|
Or use the artifact tgz together with |
|
Good idea... That will also work for PRs or devs not setting the secret. Will add this evening. |
Description
This container adds support to test the deployment and start of the RaspberryMatic container. Currently is just testing that the container comes up but in future this might be extended with any additional testcases.
Related Issue
#786
Types of changes
Alternate Designs
Manual test
Possible Drawbacks
Add a few minutes to the CI
Verification Process
CI working sucesfuly
Release Notes
NA - this is quality assurance item, not a visible feature.
Contributing checklist