* chore: replace ioutil.ReadFile by os.ReadFile
* feat: Add two template functions
- cat: Allows reading a value from a file
- credential: Allows reading a credential passed by systemd
Ensure that release builds are built with cgo disabled. This is usually the case for cross-compiled builds anyway, but adding this flag makes builds consistent regardless of what platform they are being built on.
In particular, without CGO_ENABLED=0, if you make the release builds on a linux/amd64 system then the linux/amd64 binary is dynamically linked against the system libc, meaning a binary built on a glibc-based system like Ubuntu will not work on a musl libc system like Alpine. This is what appears to have happened for release 2.8.1.
But the same source code built on a different system (e.g. darwin/arm64) would cross-compile the linux/amd64 binary with cgo disabled, making a static binary that works on both glibc and musl systems. This is what appears to have happened for release 2.8.2.
Setting CGO_ENABLED=0 in the Makefile will make the behaviour consistent for future releases, producing static binaries for the linux builds in all cases, whatever the build platform.
* feat: add support for systemd socket activation
If webhook has been launched via systemd socket activation, simply use the systemd-provided socket rather than opening our own.
* docs: documentation for the systemd socket activation mode
* refactor: moved setuid and setgid flags into platform-specific section
The setuid and setgid flags do not work on Windows, so moved them to platform_unix so they are only added to the flag set on compatible platforms.
Also disallow the use of setuid and setgid in combination with -socket, since a setuid webhook process would not be able to clean up a socket that was created while running as root. If you _need_ to have the socket owned by root but the webhook process running as a normal user, you can achieve the same effect with systemd socket activation.
* feat: add ability to listen on unix socket/named pipe
Add a -socket option that configures the server to listen on a Unix-domain socket or Windows named pipe instead of a TCP port. This allows webhook to be used behind a reverse proxy on multi-tenant shared hosting without the need to choose (and the permission to bind to) a free port number.
On Windows, -socket is expected to be a named pipe such as \\.\pipe\webhook, and the code uses https://github.com/microsoft/go-winio to bind the listening socket. On other platforms, -socket is the path to a Unix domain socket such as /tmp/webhook.sock, or an abstract socket name starting with @, bound using the regular net.Listen function with the "network" parameter set to "unix".
Note: this pushes our minimum Go version up to 1.21 as that is what go-winio requires, but that is already the minimum version against which we are testing in the CI matrix.
* tests: add test for the -socket option
Refactored webhook_test so that the test HTTP requests are made using an explicitly-provided http.Client, so we can run at least one test with the server bound to a socket instead of a port number, using an http.Client whose transport has been configured with a suitable Unix-domain or Windows named pipe dialer function.
* tests: use GOROOT to find go command
This should ensure that, even if a developer or CI server has multiple versions of go installed, the version used to build the tools under test will be the same version that is running the test harness.
* fix: clean up Unix socket file before exit
If webhook is restarted with the same settings but the socket file has not been deleted, webhook will be unable to bind and will exit with an error.
* docs: add -socket option to documentation
* docs: add a note about reverse proxies
- README mentions the idea of using webhook behind a reverse proxy, including with the -socket flag
- added a note in Hook-Rules that the ip-whitelist rule type does not work as expected behind a reverse proxy, and you should configure IP restrictions at the proxy level instead
#461 changed option name and in https://github.com/adnanh/webhook/pull/528#issuecomment-826165812, @moorereason suggests to look at old tags of example documentation. This would mean that users have to read through random old documentation to discover why their packaged version doesn't work . Suggesting that clarity in the examples is preferable.
Recall that renaming this doesn't give the user some easy exception. It just mean that the trigger isn't satisfied, so there are A LOT of options for debugging.
(which takes a lot of time to do, so that's why this information is important)
