Closed codefromthecrypt closed 3 years ago
:heavy_check_mark: Deploy Preview for archive-envoy ready!
:hammer: Explore the source changes: 6572d07b43db85d5e4beea038c14c033789d8210
:mag: Inspect the deploy log: https://app.netlify.com/sites/archive-envoy/deploys/60cc3ad06daaa800075328d6
:sunglasses: Browse the preview: https://deploy-preview-7--archive-envoy.netlify.app
@mathetake PTAL at the script headers if you don't mind. I think they hopefully make more sense now
much better I think 😄
good.. I think future me will appreciate this also :D
ok final name is bin/tar_envoy_artifact.sh as it is making the a release artifact in tar format. Thanks for all the backchannel on this @mathetake!
This allows us to archive debug builds, via a naming convention
${version}_debug
. The naming convention intentionally avoids hyphens in order to allow easy copy-paste and prevent interference on those splitting on hyphen.This also fixes #6, by including all binaries (notably we were only missing
bin/su-exec
)Many thanks to @mathetake who helped elaborate the use case of debug builds. Even if not many should need these, knowing why helps!
Debug releases
Debug versions help provide troubleshooting information to Envoy maintainers when there is a crash (Segmentation fault). A debug version ends in
_debug
(exv1.18.3_debug
) and listed in envoy-versions_debug.json.NOTE Debug builds are very large. For example, the normal build may be less than 70MB, while its debug build is >2GB. Only use debug versions in advanced situations.
The main visible change is insight into the source that led to a segmentation fault.
Ex. a normal version may crash with a backtrace like this:
A debug version has more information in the backtrace, and may lead to faster diagnosis: