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

Vendor static / generated assets #7350

Open
nilium opened this issue Aug 22, 2019 · 5 comments
Open

Vendor static / generated assets #7350

nilium opened this issue Aug 22, 2019 · 5 comments

Comments

@nilium
Copy link
Contributor

nilium commented Aug 22, 2019

Request

I'd like to see the static and generated assets (those built from with the Makefile) vendored in Vault source releases (i.e., not master, branches, or elsewhere -- just for tagged releases). This applies to the UI but also any generated protobuf, for example, that is not already vendored.

When building Vault from source, we can mostly rely on the vendor directory being up to date for Go dependencies. However, static assets still need to be built from scratch. In comparison, Consul and Nomad both vendor assets, making it easier to build them from source and produce the same binary each time.

Vendoring assets makes it far easier to package both Consul and Nomad for Void Linux as well, since we can't build Vault on every platform due to issues with yarn (outside the scope of anything Hashicorp) -- this makes cross-compilation necessary, and means that some users cannot build Vault. So, in places where Hashicorp's own binaries cannot be accepted (such as when support for static linking or musl is a requirement [see hashicorp/nomad#5535 and hashicorp/nomad#5643]), vendoring assets can make it much simpler to build, package, and run Vault.

Desired Solution

As the subject says, I'd like to see Vault's static assets vendored for release commits. I don't expect this would be done for untagged commits, similar to how the vendor directory is only consistent for releases.

Whether prerelease tags should have vendored assets, I don't know. Likely look to Consul and Nomad for guidance.

Alternatives

An alternative would be to break Vault's assets out into per-tag release archives, similar to how a source archive is made available by GitHub for each Vault tag.

Additional Use-Cases

Outside of Void Linux's troubles around building Vault, this ensures that each Vault build gets the same assets and moves it towards much simpler reproducible builds. With vendored assets, and assuming vendored Go dependencies are kept, every source release of Vault should be able to build regardless of the availability of the tools needed at the time the assets were generated.

@Conan-Kudo
Copy link

This is also valuable for me for packaging for Fedora and CentOS, as JS dependencies are difficult to get right...

@the-maldridge
Copy link

Just ran into this again today. We actually don't provide the vault UI in my environment because of how difficult it is to reliably build it from source.

@the-maldridge
Copy link

Bumping this with an update from some months later. Vault is now fails-to-build-from-source on Void due to being pinned to an ancient version of nodejs. The specific error is:

error [email protected]: The engine "node" is incompatible with this module. Expected version " >= 10.* <11". Got "12.18.4"

@FatmanUK
Copy link

FatmanUK commented Mar 4, 2022

Ticket for the nodejs issue: #8504

@Vaelatern
Copy link

Can we please have a tarball build when the releases happen with the static-assets built? Would this be accepted if I do so in the circleci config?

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

No branches or pull requests

6 participants