looterz / grimd

:zap: fast dns proxy that can run anywhere, built to black-hole internet advertisements and malware servers
MIT License
1.39k stars 108 forks source link

[Fix] allow the project to complete the build in the docker #96

Closed soulteary closed 2 years ago

soulteary commented 2 years ago

Hello maintainer 👋 @looterz

The dockerfile used by the current project needs to be used with the built binary.

If we wanted to use containers for multi-architecture builds, it would get complicated.

So I tried submitting a PR and building the program entirely inside the container.

In addition, I also use UPX to compress the program. Compared with the past, the image size of grimd will be reduced by nearly 40%, and the running and distribution speed will also become faster.

                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96        Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
   8503296 ->   3253452   38.26%   linux/amd64   grimd.minify

Packed 1 file.

Please review the code, if you have any questions, welcome to discuss in the issue, looking forward to your opinion

https://github.com/looterz/grimd/pull/95

looterz commented 2 years ago

Looks good to me, sometimes packed binaries can trigger warnings but I think we'll be okay using UPX

looterz commented 2 years ago

Looks like this may be incompatible with how goreleaser expects things to work when it builds an image, you can see goreleaser failing when building from the Dockerfile here. Will take some more investigation to figure out how to get this compatible with goreleaser, let me know if you have any ideas.

soulteary commented 2 years ago

Thanks for the feedback! @looterz

Before the merge, I couldn't observe the error because I couldn't trigger the release, sorry :( ...

In order to ensure the continuous update of the project, we should probably restore the Dockerfile first.

I'm not sure, if future projects are willing to use multi-CPU architecture and standardized builds in docker?

If we consider starting now, maybe we can temporarily allow two sets of dockerfiles to appear in the project, one for goreleaser and the other to solve the above problems. And at the right point, we will use a standard multi-container architecture build in CI, instead of goreleaser?

I'm not sure how to do better, would like to hear your suggestions and views. :D

looterz commented 2 years ago

@soulteary I was thinking the same thing, just having a separate Dockerfile for the goreleaser pipeline, seems like the easiest solution for now.

soulteary commented 2 years ago

I made a small adjustment, please help me see if it fits when you have time. https://github.com/looterz/grimd/pull/101/files

This change still needs to be merged before it can be verified. 😅 @looterz