using a

BuildService

how should I be executing an external command? I need to start a non java server; and some way to send a sigint to it later to stop it.

sigkill you should be able to send using

Process#destroy()

for example. Arbitrary signals are not supported by Java afair unless maybe you use some native library, or doing some platform specific external call that does it like invoking

kill -SIGINT ...

How does Gradle expect me to execute this? Or should I just use process builder?

What is "this"?

destroy()

? I don't think you can do that through Gradle-provided utilities but will just use `ProcessBuilder`then.

Well I was just trying to figure out if Gradle provided utilities were supposed to be used for starting this process... But from the sounds of it it sounds like no. Which kind of makes me wonder if I should actually use Gradle to start this process, or if I should just rely on it already being running

One of the typical use-cases for using a build service is, to start some external server before task that needs it starts and shutting it down after all tasks that need it have finished. There might be processes where you call some starter script that exits after invocation while the server stays running. But I think there are also quite some that would not detach and so for those you could also not use the

ExecOperations

.

Yeah it doesn't sound particularly good at it... If I have to write a script around the service in order to stop it. At that point I might as well just use a docker container... Alrighty well I have no desire to look at this further until Monday

Starting and stopping Docker or Podman container probably works quite nice as those do exactly that. They start the container and end the command you invoked.

yeah, only problem I have is I'm not certain how easy it is to run docker containers in our current CI environment

Podman is a drop-in replacement for Docker, and more. And Podman Compose for Docker Compose.

Yeah, but its documentation looks bad...

Possible, but you can just read the Docker documentation, the command should (at least for most cases) be 1:1 the same as for Docker

Podman is not an exact drop-in though, mainly because it's rootless (due to it being daemon less): • differences in UID/GID mapping which is crucial when using bind-mounts to control the files owner • can't do port mapping to privileged ports

That's not exactly right. It can be rootless and thus more secure and so on. But it can also be rootful. It just is rootless by default. Unless you install on Windows for example, where it is rootful by default.

TIL about

podman system service

which IIUC turns podman from daemonless to daemonful like Docker, and can thus easily allow being rootful without turning to

sudo

or a podman machine.