Add nightly build? #4

Closed
opened 2021-04-30 12:52:28 +00:00 by akloeckner · 13 comments
Contributor

Hey again,

do you think it might be possible to add a nightly tag that bundles the most recent master branch?

Andreas

Edit:

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...
Author
Contributor

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...
Author
Contributor

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. (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.
Owner

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?
Author
Contributor

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

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
Owner

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

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
fbrinker reopened this issue 2021-05-10 19:31:47 +00:00
Author
Contributor

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? :-/
Owner

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
Owner

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 ^^

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 ^^
Author
Contributor

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.

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

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!

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!
Author
Contributor

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!
Owner

Thank you, perfect :)

Thank you, perfect :)
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#4
No description provided.