And here is my (ugly) take on checking for changes within the latest 24h: 2bdac4108d/.github/workflows/build-dev.yml (L19), which maybe can just be skipped. Not sure about the computing resources you have in place...
Hey again,
do you think it might be possible to add a `nightly` tag that bundles the most recent `master` branch?
Andreas
Edit:
* That's the ZIP link: https://github.com/resoai/TileBoard/archive/refs/heads/master.zip
* And here is my (ugly) take on checking for changes within the latest 24h: https://github.com/akloeckner/pilight-docker/blob/2bdac4108d795c863199e2306769bf477a21768f/.github/workflows/build-dev.yml#L19, which maybe can just be skipped. Not sure about the computing resources you have in place...
I just realized that the link only gives the source, which will need to be built first. That will be more effort... I have a stub for that. i could put it on Github until we have a working version. then we can decide, if we keep it separate or if you integrate it here...
I just realized that the link only gives the source, which will need to be built first. That will be more effort... I have a stub for that. i could put it on Github until we have a working version. then we can decide, if we keep it separate or if you integrate it here...
I set it up as a multi-stage build in order to save space. But that leads to the image having a COPYed content. If we were to build in the image directly, that would blow up the image quite a lot. (yarn needs many packages and I haven't even succeeded to run it on alpine.) Not sure, what is best to do.
Upside of the multi-stage build: It also has a dev target, which might by useful as an additional tag. Caveat: The built output is located in a different directory from /tileboard. Plus yarn dev uses a different port. But maybe this is even a good thing, so people don't accidentally load a dev image for production. Not sure how to go about this either.
Edit: Working on the downsides. I also set up an automatic build with a link to your images.
Update: Downsides fixed (except the COPY statement): serve /tileboard on port 8000 for alpine based dev image.
So, here we go:
https://github.com/akloeckner/TileBoard-docker-nightly/blob/main/Dockerfile
I set it up as a multi-stage build in order to save space. But that leads to the image having a `COPY`ed content. If we were to build in the image directly, that would blow up the image quite a lot. (`yarn` needs many packages and I haven't even succeeded to run it on alpine.) Not sure, what is best to do.
Upside of the multi-stage build: It also has a `dev` target, which might by useful as an additional tag. Caveat: The built output is located in a different directory from `/tileboard`. Plus `yarn dev` uses a different port. But maybe this is even a good thing, so people don't accidentally load a `dev` image for production. Not sure how to go about this either.
Edit: Working on the downsides. I also set up an automatic build with a link to your images.
Update: Downsides fixed (except the `COPY` statement): serve `/tileboard` on port `8000` for `alpine` based `dev` image.
What is the purpose of the nightly build? For early access?
Neat solution and thank you for the link! :)
I guess it's okay for an nightly build to contain some more tools since it's mostly for developing purposes.
Should we keep those two projects seperated or would you prefer integrating it into this project?
What is the purpose of the nightly build? For early access?
Neat solution and thank you for the link! :)
I guess it's okay for an nightly build to contain some more tools since it's mostly for developing purposes.
Should we keep those two projects seperated or would you prefer integrating it into this project?
What is the purpose of the nightly build? For early access?
Yes, exactly. I'm a contributor to TileBoard and I had a fix in master which had not made it to a release yet. So, I thought: why wait?
Neat solution and thank you for the link! :)
Sure! Credit to whom credit is due. ;)
I guess it's okay for an nightly build to contain some more tools since it's mostly for developing purposes.
True. Although only dev actually has more tools. nightly works just like your release images.
Should we keep those two projects seperated or would you prefer integrating it into this project?
I'm actually proud it works in my account. But I think it's cleaner to have it in one place (your place), so people find it more easily. I can still clone it over. ;-)
(I'm also thinking to suggest a link to you from the project repo. Somewhere in the install section would be good. But that's the next step.)
There's yet the scheduled build to solve. Because I don't have a drone, I used GitHub actions.
> What is the purpose of the nightly build? For early access?
>
Yes, exactly. I'm a contributor to TileBoard and I had a fix in `master` which had not made it to a release yet. So, I thought: why wait?
> Neat solution and thank you for the link! :)
Sure! Credit to whom credit is due. ;)
> I guess it's okay for an nightly build to contain some more tools since it's mostly for developing purposes.
True. Although only `dev` actually has more tools. `nightly` works just like your release images.
> Should we keep those two projects seperated or would you prefer integrating it into this project?
I'm actually proud it works in my account. But I think it's cleaner to have it in one place (your place), so people find it more easily. I can still clone it over. ;-)
(I'm also thinking to suggest a link to you from the project repo. Somewhere in the install section would be good. But that's the next step.)
There's yet the scheduled build to solve. Because I don't have a drone, I used GitHub actions.
I'm actually proud it works in my account. But I think it's cleaner to have it in one place (your place), so people find it more easily. I can still clone it over. ;-)
Hehe I can understand that and it isn't a problem at all. We could keep the projects seperated. Feel free to add a PR to the Readme inlcuding a hint to your nightly builds if you want. Some people may benefit from that. :)
On the other hand I could create cron jobs for my drones to create a build every night if there are any new commits, if that is not possible with Github Actions (since I don't use them, I have no idea if that is possible).
I should be able to create a second pipeline with your nightly Dockerfile. So we could keep both Dockerfiles seperated as Dockerfile and Dockerfile.nightly for example.
It's up to you. Feel free to add a PR any time. Or I can "steal" your Dockerfile if you say that it is ready for "production" :D
> I'm actually proud it works in my account. But I think it's cleaner to have it in one place (your place), so people find it more easily. I can still clone it over. ;-)
Hehe I can understand that and it isn't a problem at all. We could keep the projects seperated. Feel free to add a PR to the Readme inlcuding a hint to your nightly builds if you want. Some people may benefit from that. :)
On the other hand I could create cron jobs for my drones to create a build every night if there are any new commits, if that is not possible with Github Actions (since I don't use them, I have no idea if that is possible).
I should be able to create a second pipeline with your nightly Dockerfile. So we could keep both Dockerfiles seperated as `Dockerfile` and `Dockerfile.nightly` for example.
It's up to you. Feel free to add a PR any time. Or I can "steal" your Dockerfile if you say that it is ready for "production" :D
Update: Looks like the date command can't handle the ISO8601 format github gives us. I will convert it via sed
It looks like your check doesnt work. I will look into this :)
https://drone.f-brinker.de/fbrinker/docker-tileboard/3/2/2
Update: Looks like the date command can't handle the ISO8601 format github gives us. I will convert it via sed
Update: Looks like the date command can't handle the ISO8601 format github gives us. I will convert it via sed
Probably some specialty of alpine? :-/
> Update: Looks like the date command can't handle the ISO8601 format github gives us. I will convert it via sed
Probably some specialty of alpine? :-/
Yes i think so, since it uses a very basic date runtime and not gdate or similar.
I've fixed it by using sed and replacing the Letters. This shouldn't lead to any problem in the future. Github wont change the format and even if they do, it could be compatible :D
Yes i think so, since it uses a very basic date runtime and not gdate or similar.
I've fixed it by using sed and replacing the Letters. This shouldn't lead to any problem in the future. Github wont change the format and even if they do, it could be compatible :D
https://drone.f-brinker.de/fbrinker/docker-tileboard/5/2/4
Would it be possible that you test them? If they work, we can close this :)
Meanwhile I am going to update the Readme @Dockerhub and try changing my scheduled builds to Github ^^
Whoop whoop, the images are coming in:
https://hub.docker.com/r/fbrinker/tileboard/tags?page=1&ordering=last_updated
https://drone.f-brinker.de/fbrinker/docker-tileboard/5/2/4
Would it be possible that you test them? If they work, we can close this :)
Meanwhile I am going to update the Readme @Dockerhub and try changing my scheduled builds to Github ^^
Yeay! I'll test as soon as I start my computer next time. Probably tomorrow evening.
If you like, you can copy my workflow for updating the Docker hub description. You'll need to create secrets with your username and actual password in Github. A token won't work...
Yeay! I'll test as soon as I start my computer next time. Probably tomorrow evening.
If you like, you can copy my workflow for updating the Docker hub description. You'll need to create secrets with your username and actual password in Github. A token won't work...
https://github.com/akloeckner/TileBoard-docker-nightly/blob/main/.github/workflows/update-description.yml
There are also workflows for the images.
For now I am using still my drones, but and updating the readme shouldn't occur too often. But I will look into that and keep that in mind :)
Thanks!
Ah nice :)
For now I am using still my drones, but and updating the readme shouldn't occur too often. But I will look into that and keep that in mind :)
Thanks!
Would it be possible that you test them? If they work, we can close this :)
Just pulled the dev and nightly images from your repo. Works like a charm!
> Would it be possible that you test them? If they work, we can close this :)
Just pulled the `dev` and `nightly` images from your repo. Works like a charm!
Hey again,
do you think it might be possible to add a
nightlytag that bundles the most recentmasterbranch?Andreas
Edit:
2bdac4108d/.github/workflows/build-dev.yml (L19), which maybe can just be skipped. Not sure about the computing resources you have in place...I just realized that the link only gives the source, which will need to be built first. That will be more effort... I have a stub for that. i could put it on Github until we have a working version. then we can decide, if we keep it separate or if you integrate it here...
So, here we go:
https://github.com/akloeckner/TileBoard-docker-nightly/blob/main/Dockerfile
I set it up as a multi-stage build in order to save space. But that leads to the image having a
COPYed content. If we were to build in the image directly, that would blow up the image quite a lot. (yarnneeds many packages and I haven't even succeeded to run it on alpine.) Not sure, what is best to do.Upside of the multi-stage build: It also has a
devtarget, which might by useful as an additional tag. Caveat: The built output is located in a different directory from/tileboard. Plusyarn devuses a different port. But maybe this is even a good thing, so people don't accidentally load adevimage for production. Not sure how to go about this either.Edit: Working on the downsides. I also set up an automatic build with a link to your images.
Update: Downsides fixed (except the
COPYstatement): serve/tileboardon port8000foralpinebaseddevimage.What is the purpose of the nightly build? For early access?
Neat solution and thank you for the link! :)
I guess it's okay for an nightly build to contain some more tools since it's mostly for developing purposes.
Should we keep those two projects seperated or would you prefer integrating it into this project?
Yes, exactly. I'm a contributor to TileBoard and I had a fix in
masterwhich had not made it to a release yet. So, I thought: why wait?Sure! Credit to whom credit is due. ;)
True. Although only
devactually has more tools.nightlyworks just like your release images.I'm actually proud it works in my account. But I think it's cleaner to have it in one place (your place), so people find it more easily. I can still clone it over. ;-)
(I'm also thinking to suggest a link to you from the project repo. Somewhere in the install section would be good. But that's the next step.)
There's yet the scheduled build to solve. Because I don't have a drone, I used GitHub actions.
Hehe I can understand that and it isn't a problem at all. We could keep the projects seperated. Feel free to add a PR to the Readme inlcuding a hint to your nightly builds if you want. Some people may benefit from that. :)
On the other hand I could create cron jobs for my drones to create a build every night if there are any new commits, if that is not possible with Github Actions (since I don't use them, I have no idea if that is possible).
I should be able to create a second pipeline with your nightly Dockerfile. So we could keep both Dockerfiles seperated as
DockerfileandDockerfile.nightlyfor example.It's up to you. Feel free to add a PR any time. Or I can "steal" your Dockerfile if you say that it is ready for "production" :D
It looks like your check doesnt work. I will look into this :)
https://drone.f-brinker.de/fbrinker/docker-tileboard/3/2/2
Update: Looks like the date command can't handle the ISO8601 format github gives us. I will convert it via sed
Probably some specialty of alpine? :-/
Yes i think so, since it uses a very basic date runtime and not gdate or similar.
I've fixed it by using sed and replacing the Letters. This shouldn't lead to any problem in the future. Github wont change the format and even if they do, it could be compatible :D
Whoop whoop, the images are coming in:
https://hub.docker.com/r/fbrinker/tileboard/tags?page=1&ordering=last_updated
https://drone.f-brinker.de/fbrinker/docker-tileboard/5/2/4
Would it be possible that you test them? If they work, we can close this :)
Meanwhile I am going to update the Readme @Dockerhub and try changing my scheduled builds to Github ^^
Yeay! I'll test as soon as I start my computer next time. Probably tomorrow evening.
If you like, you can copy my workflow for updating the Docker hub description. You'll need to create secrets with your username and actual password in Github. A token won't work...
https://github.com/akloeckner/TileBoard-docker-nightly/blob/main/.github/workflows/update-description.yml
There are also workflows for the images.
Ah nice :)
For now I am using still my drones, but and updating the readme shouldn't occur too often. But I will look into that and keep that in mind :)
Thanks!
Just pulled the
devandnightlyimages from your repo. Works like a charm!Thank you, perfect :)