Checking in on the "builds are automated" remark #3
Labels
Geen label
Geen mijlpaal
Niet toegewezen
2 deelnemers
Geen vervaldatum ingesteld.
Afhankelijkheden
Geen afhankelijkheden ingesteld.
Referentie: fbrinker/docker-tileboard-OUTDATED#3
Laden…
Verwijs in nieuw issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hey, nice image.
I've just started to look into automating the builds of my take on this. (https://github.com/akloeckner/TileBoard-docker) But I'd rather not duplicate any work. :-)
Unfortunately, DockerHub doesn't seem to have your newest tags of Tileboard. So, I wondered, are you actually building automatically? If so, I'm curious how you do it and where I can find the latest tags. And I would probably start contributing at some point. If not so, we could work out a way how to make it automatic...
(Also, I'd need to understand, how it works currently, since I don't find the
filesfolder, e.g., but that's probably just me...)Cheers
Andreas
Thank you :)
Yes it should be fully automated, but I just found out that my webhook didn't work as expected. I've tried something and destroyed it 🤦 Thank you for pointing that out :)
A short overview how I've solved the automation:
Release 2.5 is available now. I hope that solves your "problem" and answers your question? :)
Contributions are welcome any time. But I would like to keep the container as simple as possible. But I'm open for any ideas :)
PS: The function
downloadLatestReleasein my build.sh fetches the latest release as files.zip and unzips it into the files/ directory. That way this repository does not duplicate anything and just holds the container imageSome more background infos on
Since I always listened on pushes and triggered the builds on each push, the containers were rebuild far too often. So I've tried triggering builds on new releases only.
The problem was that my mirror doesn't now anything about tags or releases... So the builds weren't triggered. Oops... (:
Building on each push and re-pushing the container images with the same tags isn't a big deal, since nothing changed at all, but it's just unnecessary. 😅
Since my attempt on listening for releases didn't work as expected, I've added a small check in the build.sh file.
Now everything should work as intended. 🙏
Ah, now I understand. Neat solution! And thanks for the explanations and thanks for fixing it!
Also, I agree on the "as simple as possible" note. In case you haven't seen it yet, there's also a Hass.io addon here: https://github.com/resoai/TileBoard-addon. It's also basically a Docker container. But yes, somewhat more complicated...
Let me still leave a remark on the
filesfolder:I'm not sure about the standards in the docker community. For maximum transparency, I imagine, it would be nice to be able to check the container layers in docker hub. Right now, it just shows a folder having been copied. In order to check the contents, I'd need to download, run and inspect the container filesystem. If the
curlcommand were visible, the user could more easily trust that you compile what you "pretend" to.But that's just a personal liking, maybe. So, never mind, if you disagree! :-)
If you're ok with it, I'll close the issue and probably start to use your image soon!
That's an interesting point. I have to admit that I've never looked into the layers of any containers, but I've used official ones all the time 🙈
But yes, it would be easier to trust the image
It's tricky due to the automation, but I've added the download and unzip to the Dockerfile. I had to use a placeholder for the url, so I don't have to update the Dockerfile manually on every new release.
https://hub.docker.com/layers/fbrinker/tileboard/2.5.0/images/sha256-ec91c65c1a188047d9461eb65134d2b49bb7bda762f4f017e9cafa56574da7fe?context=explore
You can see the wget call & unzipping in line 17
Is that what you had in mind? 🙃
That is exactly what I had in mind! :-) Thanks!
As to the official images... Well... at some point we have to start trusting some-one. ;-) I also wouldn't examine and cross-compile my operating system... Neither have I checked the home assistant source with all its dependencies... Nonetheless, if it's possible to take ourselves out of the trust chain, we should do it. ;-)
Thanks for your support and the image again! I can't wait to get to trying it out!
I'm closing the issue as I have no open questions anymore.
It was nice getting in touch!
When playing with the nightly build, I noticed that v2.6 is not in your Docker hub. I guess, the build automation is still broken somehow?
O_O
Thank you, I have to keep an eye on that... Maybe I should activate hourly checks if the webhook fails... Should be published now. The webhook test worked and triggered a build.
The old request didn't go through
Added a nightly build last night and it worked as expected. So the maxium delay should be 24h for now... But I am wondering what may be the problem with the hook. Looking forward for the next release to check that 🤔
It might be a bit less fragile to just rely entirely on the nightly runs instead of the current (long) chain. Plus, the pull step is probably also just scheduled, right?
Yes, I could time it hourly to be more "precise". And yes, the pull checks are also timed, I think every 8hs... so... that's a good point ^^
But out of curiosity I'm wondering why it didn't work the last time