asset: use embed over vfsdata implementation#3115
Closed
jan--f wants to merge 5 commits intoprometheus:mainfrom
Closed
asset: use embed over vfsdata implementation#3115jan--f wants to merge 5 commits intoprometheus:mainfrom
jan--f wants to merge 5 commits intoprometheus:mainfrom
Conversation
Contributor
Author
|
Not really sure what I'm doing when it comes to circleCI. I'll keep working at it, but if anyone wants to help I'm all ears 👂. |
Contributor
|
Any chance of resurrecting this PR? Using the standard library |
Contributor
Author
|
Rebased. I'd love to move this forward too. @roidelapluie approved this in prometheus, maybe he can help? |
Member
|
Thanks very much @jan--f I'll take a look soon. |
Contributor
Author
|
Thanks, we probably want to figure out #3299 first, unless someone has good insight into circleCI. |
Member
|
Should we resume here now @jan--f ? |
Contributor
Author
|
@gotjosh Absolutely, I might need a day or two to get to it. |
This replicates work done in the prometheus repo in prometheus/prometheus#10220 plus a few follow up PRs. Asset compression is handled via https://github.com/prometheus/common/tree/main/assets Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
jan--f
force-pushed
the
embed-assets
branch
2 times, most recently
from
be0e56e to
7679407
Compare
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
This will cause a lint failure Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
Contributor
Author
|
Seems like the circleci pipeline is running into https://discuss.circleci.com/t/orbs-cannot-find-a-definition-for-command-named/34530 @gotjosh wdyt...should I work on both fixing the circleci orb and the actions workflow or is there a reason to prioritize one over the other? |
Contributor
|
Hello @jan--f , Sorry for having you wait this long. I definitely think this change is worth updating. The Circle CI is no longer relevant, and your GH action change was merged. So, I would assume this unblocks this change. Can you pick this up again or do you want to delegate this? I'll provide some speedy reviews. Kind regards, Solomon Jacobs |
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 21, 2026
This change removes the final usage of `shurcooL/vfsgen`. The change has
a couple of benefits:
* We no longer check in binary data. This improves the code review
process and reduces merge conflicts.
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
Additional differences between `vfsgen` and `embed`.
1) `embed` does not compress files, wheras `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
10 tasks
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 22, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 23, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Feb 26, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
pull bot
pushed a commit
to Mu-L/alertmanager
that referenced
this pull request
Feb 26, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
coatico
pushed a commit
to coatico/alertmanager
that referenced
this pull request
Mar 10, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
Signed-off-by: VAN LINT <marnix.vanlint@worldline.com>
coatico
pushed a commit
to coatico/alertmanager
that referenced
this pull request
Mar 10, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
Signed-off-by: VAN LINT <marnix.vanlint@worldline.com>
SoloJacobs
added a commit
to SoloJacobs/alertmanager
that referenced
this pull request
Mar 15, 2026
This change removes `shurcooL/vfsgen`. The change has a couple of
benefits:
* Fewer dependencies.
* Simplifies the build process for downstream distributions such as
Debian.
* Removes logic around different build targets.
A few additional differences between `vfsgen` and `embed` now follow.
1) `embed` does not compress files, whereas `vfsgen` compresses the files
before adding them to the binary. However, the files are decompressed
before sending them. This means that the binary size in this change
slightly increases:
```sh
❯ du alertmanager-vfsgen
40540 alertmanager-vfsgen
❯ du alertmanager-embed
41756 alertmanager-embed
```
In the future, we should ensure that we only send compressed files over
the network. Moreover, we should compress the files before the build.
2) `vfsgen` will memory map the files on startup, i.e.,
```go
var Assets = func() http.FileSystem {
fs := vfsgen۰FS{ // map-like type
```
`embed` serves files from read-only section of the binary, see
https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151
For this reason, this change should reduce the overall heap usage and
startup time.
3) The build still appears to be reproducible, tested by touching
`ui/app/script.js`. This is a deliberate decision in `embed`, i.e.,
golang/go#44854
4) With this change, we no longer send the `Last-Modified: Thu, 01 Jan
1970 00:00:01 GMT` HTTP header. Since we have disabled all caching,
this seems fair. In the future, we should enable caching.
Closes: prometheus#3115
Signed-off-by: Solomon Jacobs <solomonjacobs@protonmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This replicates work done in the prometheus repo in prometheus/prometheus#10220 plus a few follow up PRs. Asset compression is handled via https://github.com/prometheus/common/tree/main/assets
Signed-off-by: Jan Fajerski jfajersk@redhat.com