Release: Stripped & Non-Stripped Builds

[cipherboy]

As mentioned upstream on hashicorp/vault#22893 (comment):

We are aware of the size of the binary. Many design decisions are a factor, for example the debug symbols upon which many of our customers rely for information and troubleshooting.

(which was mentioned after debug symbols were re-added after removal in hashicorp/vault#20294 as mentioned in hashicorp/vault#21069 as well).

Certain vendors' offerings require non-stripped release builds to instrument the binary in production for monitoring. Unfortunately, in Go in particular, this greatly bloats binary size. Having both options (stripped and non-stripped) built from the same SHA would be great to let users choose between a smaller binary size versus needing debug symbols.

Additionally, something like UPX can be considered to compress portions of the binary to further reduce the size (at the expense of slightly slower startup & release build times -- though, this could be only done for the server and proxy binaries if separated, and not the user-facing CLI).

This compliments the size reduction in #64 and #73.

[cipherboy]

I have a draft PR here with this: cipherboy#2

The regular binary versus stripped binary sizes are:

-rwxr-xr-x. 1 cipherboy cipherboy 136M Mar 16 19:28 bao
-rwxr-xr-x. 1 cipherboy cipherboy 97M Mar 16 19:29 bao-stripped

@naphelps Do you think this is small enough to be worth the duplicate effort? This doubles the number of binaries to release, excluding container images.

Thoughts from the community at large?

[naphelps]

@cipherboy I am not sure if our community today has any small size requirements. I imagine there will be those long term who will try experimenting running a bao instance in ever greater constrained devices. I am sure it would bolster support in the Edge space :). We could always setup the pipelines for producing the smaller binaries, and limit the releases that include the smaller binaries until we have a need from the community.

A will add this issue to agenda for this week.

[cipherboy]

@naphelps Perfect! I think size requirements also come from cloud deployments, as bandwidth costs mean that constantly pulling large images can become pricey. So I wouldn't limit this just to edge or IoT applications. :-)

[joewxboy]

@cipherboy If anyone in the community has size requirements, it would likely be EdgeX Foundry (James Butcher).