We have nice release names in https://github.com/sourcegraph/sg/releases, but it's not actually programmatically available - this causes a discrepancy between the `sg` version one might pull, and the version of `sg` that is known in-code, and means that we can't do something like #62134.
This change adds a `ReleaseName` variable to be stamped at build/release time, and updates a few references to `BuildCommit` where I think it might be more prudent to report `ReleaseName` instead, and also fixes some yellow squiggles in my IDE on files I visited (sorry) and some noisy `-v` output (sorry again)
## Test plan
```
$ go build -ldflags "-s -w -X main.BuildCommit=$(git rev-list -1 HEAD .) -X main.ReleaseName=hello-world" -o ./sg ./dev/sg
$ ./sg version
hello-world
$ ./sg -v version
Version: hello-world
Build commit: b23db0be5e
```
The eventual goal is to be able to generate a spec somewhat close to the infrastructure definitions for Cody Gateway today based on the way we generate infrastructure for Cloud - see go/rfc-msp . This PR is a first-step prototype to demonstrate CDKTF integration, draft out the sketch as proposed in go/rfc-msp, and lay out some basic architecture for the stuff. A barebones CDKTF setup that imitates ~most of the Cody Gateway setup can be generated and interacted with (see test plan), but has not been applied live anywhere - a few components are still missing, and a migration plan needs to be determined.
The current goal is to land this PR as-is and iterate from here. The new command set `sg msp` is only included with the `msp` build tag, so it won't be distributed just yet. To install a version of `sg` that includes a functional `sg msp` command, run:
```
go build -tags=msp -o=./sg ./dev/sg && ./sg install -f -p=false
```
In a vanilla build of `sg`, you'll get an error when trying to use `sg msp`:
## Binary size
Thanks to Michael's improvements to generated CDKTF Go modules, we are not looking at a 500MB increase in `sg` binary sizes, but we are still faced with a ~20% increase at the moment:
```sh
# Fresh sg installation
$ curl --proto '=https' --tlsv1.2 -sSLf https://install.sg.dev | sh
$ du -h $(which sg)
132M /Users/robert@sourcegraph.com/.sg/sg
# MSP-enabled sg build
$ go build -tags=msp -o=./sg ./dev/sg && du -h ./sg
161M ./sg
```
However, the _default_ build of `sg` continues to not include `msp`, so the binary size remains the same:
```sh
$ go build -o=./sg ./dev/sg && du -h ./sg
132M ./sg
```
## Architecture
See `dev/managedservicesplatform/internal/stack/README.md` and `dev/managedservicesplatform/internal/resource/README.md` for some rudimentary docs on some CDKTF conventions.
## Specifications
Set up initial specifications here: https://github.com/sourcegraph/managed-services
## Test plan
Currently:
```
go build -tags=msp -o=./sg ./dev/sg && ./sg msp generate -o=./tmp ./dev/sg/msp/example/example-service.service.yaml dev
```
And check out the `./tmp` output. Each module is plan-able out of the box right now, as we default to a local Terraform backend:
```
cd ./tmp
asdf install # a .tool-versions is generated
cd stacks/project
terraform init
terraform plan
```
---------
Co-authored-by: Joe Chen <joe@sourcegraph.com>
syscall.Exec will cause the current command's finalizer to not run, so we make a custom call to Persist to make sure the auto_update event is tracked in success scenarios.
Also logs unexpected error events and skip events during auto-updates.
Four major changes:
- Rename stdout to std, so that it reads nicer: std.Out instead of stdout.Out
- Wrap output.Output with std.Output so that we can build wrappers on top. This wrapper is also used to generate Buildkite log output anchors (https://buildkite.com/docs/pipelines/managing-log-output), which helps us manage CI output.
- Migrating printing.go into std.Output, and rename a few to make them more purposeful: orangeLinef -> WriteAlertf, and so on. This will help us align sg output across the tool. Moving to std.Out also allows sg packages outside of main to share formatting primitives.
- Add aliases for Line and Linef that does not provide all arguments: output.Styled, output.Emoji, and friends. The pattern of omitting output.Style or emoji is so common that I think it is worth introducing special aliases for them to avoid constantly having to enter blank arguments.
Minor changes:
- Add an error handler that writes pretty failure notice instead
- Introduce NewEmptyExitErr for denoting exit errors, instead of using os.Exit
