Skip to content

chore: Remove Docker as a build dependency#5092

Merged
SoloJacobs merged 2 commits intoprometheus:mainfrom
SoloJacobs:remove-docker
Mar 26, 2026
Merged

chore: Remove Docker as a build dependency#5092
SoloJacobs merged 2 commits intoprometheus:mainfrom
SoloJacobs:remove-docker

Conversation

@SoloJacobs
Copy link
Copy Markdown
Contributor

@SoloJacobs SoloJacobs commented Mar 14, 2026

The advantages and disadvantages of this PR are described in the commit message. The main motivation is the we use prom crossbuild, which does not allow using Docker during the build step. Because we can't execute the build steps during the cross build, we are forced to check our build artefacts into the source code.

Pull Request Checklist

Which user-facing changes does this PR introduce?

NONE

@SoloJacobs
Copy link
Copy Markdown
Contributor Author

What I did not do yet: Add caching for node_modules and ensure dependabot actually finds our packages.json.

@SoloJacobs SoloJacobs force-pushed the remove-docker branch 2 times, most recently from a10ca09 to 90c358f Compare March 14, 2026 13:56
@SoloJacobs SoloJacobs requested a review from w0rm March 14, 2026 14:23
Copy link
Copy Markdown
Contributor

@siavashs siavashs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to clean up the Makefile (see comment below) and ui/app/ CONTRIBUTING.md too

There are a few advantages to this setup:

* Dependabot can now help with keeping versions recent.
* The setup is more idiomatic and simpler. In particular, our build
  steps are more deterministic due to the inclusion of
  `package-lock.json`.
* We have to get rid of the Docker based approach for the mantime ui, so
  this change makes things more uniform across the repo.
* The command `promu crossbuild` does not support running Docker. With
  this change, we could delete `email.tmpl` from our repo, and it would
  not affect our build process in any way.

The disadvantage is that this setup requires a local toolchain (stored
in `template/node_modules`) to update `email.tmpl`.

Why does this PR not delete `email.tmpl`? This file is small, and `go`
developers do not need to install any `node` tools to run.

```sh
go get github.com/prometheus/alertmanager/template
```

Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
There are a few advantages to this setup:

* Dependabot can now help with keeping versions recent.
* The setup is more idiomatic and simpler. In particular, our build
  steps are more deterministic due to the inclusion of
  `package-lock.json`.
* We have to get rid of the Docker based approach for the mantime ui, so
  this change makes things more uniform across the repo.
* The command `promu crossbuild` does not support running Docker. With
  this change, we could delete `ui/app/script.js` from our repo, and it
  would not affect our build process in any way.
* This change should help users, which are building `podman` with
  `Alertmanager`.

The disadvantage is that this setup requires a local toolchain (stored
in `ui/app/node_modules`) to update `ui/app/script.js`.

The file `ui/app/script.js` will be removed from the repo in a future
commit. This will break the following invocation:

```sh
go get github.com/prometheus/alertmanager/ui
```

The dependency `openapitools/openapi-generator-cli` could not be
removed, since it depends on `Java`.

Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
@ultrotter
Copy link
Copy Markdown
Contributor

Have we tried podman?
And could we leave the option of containerized build in case people don't want to pull random npms?

@SoloJacobs
Copy link
Copy Markdown
Contributor Author

@ultrotter It depends on what you mean.

Before podman did not work correctly, see this experiment by Christoph: https://gist.github.com/TheMeier/1ea1ff5a9166d4980309b4621ad8f751
I believe this was due to way we used bind mounts, but I'm not sure.

You always had to pull the npm dependencies, this was simply done during the docker build step. This now arguably less random with package-lock.json. I don't see anyway of avoiding this, unless we want to host build images, which have our specific dependencies installed.

This PR specifically removes docker, so we are compatible with promu. You can run your build fully containerized with podman like so:

promu crossbuild --podman -p linux/amd64

What you can't do is use the created artifacts locally (except for alertmanager and amtool). This does not matter right now, since script.js is checked into the repo. But might matter in the future. Currently, promu does the following steps:

  • docker create the container
  • docker cp your local files into the container (/app/)
  • docker start (runs the build, specifically make build)
  • docker cp only .build/ back out (everything else, including the node_modules is lost)
  • docker rm

There used to be bind-mounts in promu, which would enable the creation of build artefacts locally. We could consider adding them back: prometheus/promu#95

@ultrotter
Copy link
Copy Markdown
Contributor

@SoloJacobs What I meant is having an easy target that can build the tools "in a container" with a Dockerfile that pulls the build deps... It could be easy for the target to do
"container up"
"build"
"run tests"
"copy artifacts"
"container down"

This is pretty much what you described and might not need (write) bind mounts at all...

@SoloJacobs
Copy link
Copy Markdown
Contributor Author

To move things forward a bit, I would like to add this extra target after the ui changes have landed. I did add the build target you requested here: #5102

@SoloJacobs SoloJacobs merged commit 2e46186 into prometheus:main Mar 26, 2026
7 checks passed
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

Successfully merging this pull request may close these issues.

5 participants