sourcegraph/dev/sg/sg_version.go

113 lines
3.1 KiB
Go
Raw Permalink Normal View History

package main
import (
"fmt"
"os"
"os/exec"
"strings"
"github.com/urfave/cli/v2"
sg msp: initial prototype (#55905) 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`: ![image](https://github.com/sourcegraph/sourcegraph/assets/23356519/15c6cde2-25c2-439e-b41d-b674cc36f23f) ## 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>
2023-09-08 00:24:34 +00:00
"github.com/sourcegraph/sourcegraph/dev/sg/internal/category"
"github.com/sourcegraph/sourcegraph/dev/sg/internal/run"
"github.com/sourcegraph/sourcegraph/dev/sg/internal/std"
"github.com/sourcegraph/sourcegraph/lib/errors"
"github.com/sourcegraph/sourcegraph/lib/output"
)
var (
versionChangelogNext bool
versionChangelogEntries int
versionCommand = &cli.Command{
Name: "version",
Usage: "View details for this installation of sg",
Action: versionExec,
sg msp: initial prototype (#55905) 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`: ![image](https://github.com/sourcegraph/sourcegraph/assets/23356519/15c6cde2-25c2-439e-b41d-b674cc36f23f) ## 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>
2023-09-08 00:24:34 +00:00
Category: category.Util,
Subcommands: []*cli.Command{
{
Name: "changelog",
Aliases: []string{"c"},
Usage: "See what's changed in or since this version of sg",
Flags: []cli.Flag{
&cli.BoolFlag{
Name: "next",
Usage: "Show changelog for changes you would get if you upgrade.",
Destination: &versionChangelogNext,
},
&cli.IntFlag{
Name: "limit",
Usage: "Number of changelog entries to show.",
Value: 5,
Destination: &versionChangelogEntries,
},
},
Action: changelogExec,
},
},
}
)
func versionExec(c *cli.Context) error {
chore(local): clear ambiguity in between sg version|live (#64122) Context: As I was catching up with my Slack notifications, I spotted this [conversation](https://sourcegraph.slack.com/archives/C04MYFW01NV/p1721137862832899?thread_ts=1721136881.733869&cid=C04MYFW01NV) and this PR is a 5m fix to avoid the problem to happen again. What: If you haven't used `sg` in a while, it's easy to think that `sg version` refers to the currently deployed Sourcegraph instance and not the CLI. This commit adds a little preamble on stderr to not mess with script usage while still reminding the user that it's the CLI version that gets printed out. Before: we printed the version without any context After: we also print the following on stderr: `👉 Showing the current version of the sg CLI, if you're looking for deployed Sourcegraph instances version, please use `sg live` instead.`. Stderr so we don't break things like `$(sg version)`. Note: at a broader level, we should generalize this pattern, we don't use too much `sg` raw output in scripts, but for the few places where it's the case, it's a footgun. <!-- PR description tips: https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e --> ## Test plan Locally tested + CI. <!-- REQUIRED; info at https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> ## Changelog - `sg version` explicitly mentions that it's the CLI version that's printed out, not any instance version. <!-- OPTIONAL; info at https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c -->
2024-08-07 16:34:38 +00:00
// Write on stderr to ensure we can use the output in scripts without having to trim
// the output from the contextual infos.
outErr := std.NewOutput(os.Stderr, verbose)
outErr.WriteNoticef("Showing the current version of the sg CLI, if you're looking for deployed Sourcegraph instances version, please use `sg live` instead.")
if verbose {
std.Out.Writef("Version: %s\nBuild commit: %s",
c.App.Version, BuildCommit)
} else {
std.Out.Write(c.App.Version)
}
return nil
}
func changelogExec(ctx *cli.Context) error {
if _, err := run.GitCmd("fetch", "origin", "main"); err != nil {
return errors.Newf("failed to update main: %s", err)
}
logArgs := []string{
// Format nicely
"log", "--pretty=%C(reset)%s %C(dim)%h by %an, %ar",
"--color=always",
// Filter out stuff we don't want
"--no-merges",
// Limit entries
fmt.Sprintf("--max-count=%d", versionChangelogEntries),
}
var title string
if BuildCommit != "dev" {
current := strings.TrimPrefix(BuildCommit, "dev-")
if versionChangelogNext {
logArgs = append(logArgs, current+"..origin/main")
title = fmt.Sprintf("Changes since sg release %s", ReleaseName)
} else {
logArgs = append(logArgs, current)
title = fmt.Sprintf("Changes in sg release %s", ReleaseName)
}
} else {
std.Out.WriteWarningf("Dev version detected - just showing recent changes.")
title = "Recent sg changes"
}
gitLog := exec.Command("git", append(logArgs, "--", "./dev/sg")...)
gitLog.Env = os.Environ()
out, err := run.InRoot(gitLog, run.InRootArgs{})
if err != nil {
return err
}
block := std.Out.Block(output.Styled(output.StyleSearchQuery, title))
if len(out) == 0 {
block.Write("No changes found.")
} else {
block.Write(out + "...")
}
block.Close()
std.Out.WriteLine(output.Styledf(output.StyleSuggestion,
"Only showing %d entries - configure with 'sg version changelog -limit=50'", versionChangelogEntries))
return nil
}