Checking in on the "builds are automated" remark #3

New Issue

akloeckner · 2021-04-21T15:58:30Z

akloeckner commented

2021-04-21 15:58:30 +00:00

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 files folder, e.g., but that's probably just me...)

Cheers
Andreas

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 `files` folder, e.g., but that's probably just me...) Cheers Andreas

👍 1

fbrinker commented

2021-04-21 20:53:18 +00:00

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:

I have a private mirror hosted here of the original tileboard repository
Everytime the original repository is updated, my mirror fetches the changes
On every change (push) my mirror triggers a webhook (php script), starting a build on my build server (selfhosted drone.io instance)
My build server builds this repository (the container) with the latest official tileboard release and publishes it to the docker hub

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 downloadLatestRelease in 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 image

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: 1. I have a private mirror hosted here of the original tileboard repository 2. Everytime the original repository is updated, my mirror fetches the changes 3. On every change (push) my mirror triggers a webhook (php script), starting a build on my build server (selfhosted drone.io instance) 4. My build server builds this repository (the container) with the latest official tileboard release and publishes it to the docker hub 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 `downloadLatestRelease` in 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 image

fbrinker commented

2021-04-21 22:15:23 +00:00

Some more background infos on

I've tried something and destroyed it 🤦

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. 🙏

Some more background infos on > I've tried something and destroyed it 🤦 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](https://git.f-brinker.de/fbrinker/docker-tileboard/src/branch/master/build.sh#L31-L36) in the build.sh file. Now everything should work as intended. 🙏

fbrinker self-assigned this 2021-04-21 22:17:57 +00:00

akloeckner commented

2021-04-22 08:58:30 +00:00

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 files folder:

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 curl command 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!

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 `files` folder: 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 `curl` command 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!

fbrinker commented

2021-04-22 20:38:03 +00:00

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'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? 🙃

akloeckner commented

2021-04-23 08:18:34 +00:00

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!

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!

akloeckner closed this issue

2021-04-23 08:18:34 +00:00

akloeckner commented

2021-05-09 21:25:25 +00:00

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?

❤️ 1

akloeckner reopened this issue

2021-05-09 21:25:25 +00:00

fbrinker commented

2021-05-09 21:52:59 +00:00

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

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

fbrinker commented

2021-05-10 07:44:40 +00:00

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 🤔

akloeckner commented

2021-05-10 09:08:34 +00:00

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?

It might be a bit less fragile to just rely entirely on the nightly runs instead of the [current (long) chain](https://git.f-brinker.de/fbrinker/docker-tileboard/issues/3#issuecomment-41). Plus, the pull step is probably also just scheduled, right?

fbrinker commented

2021-05-10 09:13:44 +00:00

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

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

This repo is archived. You cannot comment on issues.

No Label

No Milestone

No Assignees

2 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: fbrinker/docker-tileboard-OUTDATED#3