search

3x3cut0r / docker

several docker containers
https://github.com/3x3cut0r/docker
23 stars 9 forks source link

Distinct build for each docker image #1

Closed GioF71 closed 9 months ago

GioF71 commented 2 years ago

Hello, I am using your container image on a raspberry pi 3 since at least a year, with great success. So first of all I would like to thank you for your work.

Lately, I see the image gets updated very frequently, even when the repository changes do not directly affect dhcpd. Would it be possibile to either split the repo into multiple ones, or (somehow) build the new images only when there are relevant changes?

Thank you.

3x3cut0r commented 2 years ago

hi, thank you and great to hear that somebody is using my images :P

what is the actual problem of building new images in that high frequency? I can't see any problem with it right now. so please, enlighten me! :-)

but yeah you are right. the frequency is high with a new build every hour for no reason .... so i see 3 options on this with whom I can arrange myself:

  1. i don't do anything but reduce the frequency to, lets say, 1 time per week or so.
  2. i reduce the frequency and split the build into two tags:
    • latest: which is the same as now -> new build every week
    • version tag, e.g.: 3.15.4 (alpine version for example) ... which is the only thing atm which is really changing -> without new builds for the same version
  3. also 2 tags (latest + version tag) -> new builds only on changes

i would perfer option 2.

GioF71 commented 2 years ago

Hello, thank for you answer. Of course no, it is not really a big problem, it is just something not necessary because some build are created for no reason just like you say. Of course I hope I have not been offensive in any way, that was not the intention. I really like your work. Yours is one of the few (it not the only) isc-dhcp image built for the most relevant platforms (like for example arm and arm64) with a good documentation on docker hub and/or github.

There might be other similar images on docker hub, they might of course work perfectly, but I believe that without a good documentation, they are just unusable for the public.

It's only a matter of making the process more streamlined I believe. Solution 3 would be definitely perfect IMO, but solution 2 would work too of course.

About solution 2, I did not understand what happens for version 3.15.4: would this tag get overwritten every week? It would still make sense, because packages on the base images of course are updated all the time. What about also creating another tag when you build, which might include the build date. Like for example, for tomorrow, a tag name might be:

3x3cutor/isc-dhcp-server:3.15.4-2022-04-28

or something similar.

What do you thing?

Again, thank you for the great work!

Thank you

3x3cut0r commented 2 years ago

Hi, first of all no! you have not been offensiv and i appreciate constructive criticism in any way!

About solution 2, I did not understand what happens for version 3.15.4: would this tag get overwritten every week?

no

my thoughts about not rebuilding a tag frequently: the image won't get any package updates anymore. in the special case of isc-dhcp-server ... the package "dhcp" will not be updated anymore. i can maybe workaround on this by adding a "apk update" before starting the service. the image doesn't change, but the packages inside will still be updated! this may work with no issues and further attention on simple projects like this ... but not if a package is under heavy development. then it need some more attentien i think

maybe i can check if a image hash has change after build ... if not: i do not push it to dockerhub. the question is: does a docker image hash change after a package has updated? or does docker image hashed refer only on the RUN command in the dockerfile?

i think i need some more thoughts on this

GioF71 commented 2 years ago

Hello, sorry for answering late. Busy days. About your question, as far as I know the image hash does change after a package is updated, because at least one layer has changed. That's how docker works and is the reason for keeping the most 'stable' operations (those which do not change too frequently) in the first stages of your Dockerfile. Of course, when the base image changes, your whole image changes as well. That might be a reason for setting the image base with a date-specific tag instead of the latest tag. Apart for guaranteeing that only your changed layers are regenerated, this also gives you some guarantee of stability. Newer version of base images might break your build for any reason. I hope this helps! Thank you Giovanni