Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create goreleaser config to make building and releasing rouetdns packages easier #393

Open
mattkeenan opened this issue May 21, 2024 · 5 comments
Assignees

Comments

@mattkeenan
Copy link
Collaborator

I have an initial configuration for goreleaser that I can contribute to make it easier to build binaries and packages. It is just a first version for the moment and doesn't include docs, systemd, sysv-init, etc files (which I can provider after the initial commits).

I'll create a PR for this issue as well.

@mattkeenan
Copy link
Collaborator Author

@folbricht i'll keep this issue open as i add further config changes for a better package.

to that end, what other files do you think we should include by default?

  • systemd
  • sysv-init
  • man page(s); routedns(8), routedns.toml(5) ??
  • include example config files in the package?

also, i run ubuntu, and have been using debian for a few decades, so i know how to make the deb packages reasonably compliant. but it's been a long long time since i've done active rpm packaging, so not only rusty but also plenty of changes no doubt. would you or anyone else on the team be able to sanity check our rpm packages?

i've also included windows and darwin (macos) in the build process by default.

@mattkeenan
Copy link
Collaborator Author

also, do you want me to create a base doc file for using goreleaser? aka goreleaser.md file with a brief explanation on how to use for not only us, but also in case end users want to use goreleaser for their own local purposes?

@folbricht
Copy link
Owner

Thanks for doing this. As for your questions:

  • We should probably include a reasonable systemd service file. Not so sure about sysV though. Is there anything still using those?

  • Man pages would be nice. We may be able to generate them for the main executable at least since it uses cobra.

  • It's likely best to include a simple default config to get things started. It could be as simple as a TCP/UDP listener forwarding to quad9 or something, perhaps even a fast quic resolver. If there's a good spot for the other examples, they could be included. Or just have a pointer in the default config to https://github.com/folbricht/routedns/blob/master/doc/configuration.md and https://github.com/folbricht/routedns/tree/master/cmd/routedns/example-config

  • It's been a long while since I last made an RPM myself, but I run Fedora so should be able to test something.

  • A goreleaser.md file would be nice to have. Could put it in the doc/ dir and link to it from the main README.md

@mattkeenan
Copy link
Collaborator Author

  • sysv-init; there are distros that specifically avoid systemd as well as *BSD, but obviously I don't think we are packaging for those by default. It would probably be enough to have an example sysv-init file in the repo but elide it for packaging purposes
  • man pages; we could use the cobra method to produce markdown docs (which can then produce manpages for the binary as well as the config files). we could adapt the configuration.md to produce the routedns.toml file if you wish. personally i have used go-md2man before as it produces "light weight" man pages (i.e. no need to worry about lots of esoteric man features)
  • default config; i have a default caching config that uses cloudflare quic, 9.9.9.9 dot, cloudflare dot with fail-back and a localhost udp listener if you want

with the goreleaser.md file; i'll whip up a quick cheat sheet, and you can use it as a starting point for local testing as well as publishing.

As to the rpms sure, if you could test them that would be great.

Given that some of these changes might possibly overwrite (depending on the user's distro / settings) previous local configuration that someone made by hand before installing the package would you prefer to test this on a separate branch before merging to main?

@mattkeenan mattkeenan self-assigned this May 22, 2024
@folbricht
Copy link
Owner

Sounds great. I don't think we need a separate branch for testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants