Go Release

A graphical workflow for building, testing, packaging and releasing Go applications that ship several executables — API servers, workers, migration tools, code generators — without hand-assembling GOOS=… GOARCH=… go build … command lines.

Go Release is an independent project. It is not affiliated with or endorsed by the Go project or Google. The icon is original artwork that only borrows Go's cyan color family.

What it does

• Discovers executables with go list (never by directory name alone): every package main, across nested modules, honoring build tags. Add, edit, disable and remove commands by hand.
• Command Manager: per-command build, test, run, debug, include/exclude, arguments, environment, working directory, tags, linker flags and CGO.
• Dashboard (Activity Bar → Go Release → Open Dashboard): project overview, commands, build configuration, target platforms, live output, structured compiler errors, artifacts, history and retry-failed.
• Cross-compilation to Windows, macOS, Linux, FreeBSD and js/wasm, validated against go tool dist list, with explicit diagnostics when a target needs a C cross-compiler (cgo).
• Release profiles (Development, Testing, Production, Full cross-platform, Custom) stored in a version-controllable go-release.json, validated against a documented JSON schema, migrated automatically.
• Packaging: raw binaries per platform, .zip and .tar.gz archives, checksums.txt (SHA-256), release-manifest.json, optional reproducible-build settings. Secrets (.env, private keys …) are never packaged.
• GitHub Releases (optional): creates a draft, uploads archives/checksums/manifest, resumes interrupted uploads. Making a release public is a separate, explicit confirmation.

Requirements

• VS Code 1.90 or later, desktop (local file system), trusted workspace.
• The Go toolchain on PATH (or set goRelease.goPath).
• Git is optional (used for branch/commit/dirty status and the build date of reproducible builds).
• No Docker, virtual machine or paid service is needed for local builds.

Install

From the Marketplace: search for Go Release (publisher abdelazizaouiche0725), or install a VSIX:

code --install-extension go-release-0.1.7.vsix

First run

1. Open a folder containing a go.mod (a multi-module repository works).
2. Click the Go Release icon in the Activity Bar; discovered commands are listed. Tick the ones that belong to the release.
3. Run Go Release: Open Dashboard, pick a profile (start with production), choose version and targets, Save profile (this creates go-release.json).
4. Build, Run tests, Package, or Create release (tests → build → package → checksums → manifest).
5. Optionally GitHub draft… to upload to a draft release, review it on GitHub, then Publish draft… when you are sure.

Artifacts are written to <outputDir>/<version>/:

dist/1.0.0/
├── linux-amd64/api  migrate  tools
├── windows-amd64/api.exe …
├── archives/myapp_1.0.0_linux_amd64.zip  …tar.gz
├── checksums.txt
└── release-manifest.json

Commands

Making a draft public is only available from the dashboard's Publish draft… button and always asks again.

Configuration

go-release.json (workspace root; commit it) — see schemas/go-release.schema.json. VS Code offers completion and validation automatically.

{
  "schemaVersion": 1,
  "activeProfile": "production",
  "commands": [{ "dir": "cmd/api", "name": "api", "tags": ["jsoniter"] }],
  "profiles": {
    "production": {
      "version": "1.4.0",
      "outputDir": "dist",
      "commands": ["cmd/api", "cmd/worker"],
      "targets": ["linux/amd64", "linux/arm64", "darwin/arm64", "windows/amd64"],
      "ldflags": "-s -w -X main.version={{version}} -X main.commit={{commit}} -X main.date={{date}}",
      "cgoEnabled": false,
      "reproducible": true,
      "packaging": { "formats": ["zip", "tar.gz"], "checksums": true, "manifest": true, "extraFiles": ["README.md", "LICENSE"] },
      "github": { "repo": "owner/name", "tagPrefix": "v" }
    }
  }
}

Extension settings: goRelease.goPath (machine scope) and goRelease.maxLogLines.

Shipping without a .env file

.env files and private keys are never packaged. If your app needs a private CA, list only the certificate (for example rootCA.pem) in Extra files: certificate-only PEM files are allowed, and Go Release copies them next to each platform's binary and into every archive, so the folder runs as-is. Anything containing a private key is refused. Your program must not require .env at startup — bake defaults in with linker flags (-X main.apiURL=https://…) or go:embed a non-secret default config. Set the App name in Build configuration to control archive and release names.

Packaging command (your own tool, e.g. embedding .env)

If your project already has a packaging tool, such as go run ./cmd/tools package --env .env --out dist/RXEGoOp.exe, set Packaging command in the dashboard (use the preset button for that exact form): command package cmd/tools, arguments package --env {env} --out {out}, env file .env, output {os}-{arch}/{app}{ext}. Create release then runs the tool once per selected target (it runs on your machine; the target is passed as GO_RELEASE_GOOS, GO_RELEASE_GOARCH and {os}/{arch}) and packages what it writes under <outputDir>/<version>/. It asks for confirmation first because it executes code from your workspace. The .env file is read only by your tool and is never copied by Go Release. Output that embeds secrets must not go to a public release.

Start script for apps that require secrets

If your server refuses to start without variables such as JWT_SECRET, set Start script in the dashboard (command server, secrets JWT_SECRET). Run start.bat (Windows) or ./start.sh instead of the executable: on the first run it generates a random 64-character secret into data/JWT_SECRET.secret and reuses it afterwards; a value you set yourself always wins. The Windows script is generated to be correct but has only been tested for text content, not executed, in this version.

Cross-compilation limits

Go cross-compiles pure Go programs for almost any supported target with CGO_ENABLED=0. That is what Go Release defaults to. If a program (or a dependency) uses cgo, building for another OS/architecture needs a C cross-compiler (set CC/CXX in the profile environment) and, for macOS and Windows, the platform SDK/headers. Go Release warns in advance and explains failures, but it cannot supply those toolchains. For such targets, build on a matching machine — for example a CI matrix job per OS — and use Go Release there. Docker, VMs or hosted runners are not required for pure-Go builds and are never started by this extension.

Not provided in this version: Windows installers, macOS .pkg, Linux .deb/.rpm, code signing and notarization. Producing a raw executable or archive is not equivalent to a signed native installer.

GitHub authentication

Uploading uses VS Code's built-in GitHub sign-in (repo scope, requested only when you start a GitHub action). Tokens are held by VS Code, never written to settings, logs, manifests or archives. Without a network or sign-in, everything local still works.

Privacy and security

No telemetry. The only network traffic is what the Go toolchain does (module downloads) and the GitHub API calls you explicitly start. Webview messages are validated, the webview has a nonce-based CSP, processes run without a shell, output paths are confined to the workspace (including symlink checks), and shared configuration cannot set toolchain-hijacking environment variables. Details: docs/security.md and SECURITY.md.

Known limitations

• Desktop VS Code with a local, trusted workspace only. Virtual workspaces are unsupported. Remote Development (SSH, WSL, Dev Containers) is untested; the extension runs in the workspace extension host there, but this has not been verified.
• Developed and tested on macOS (Apple Silicon). Windows and Linux hosts are not yet tested; path handling is written to be portable (see docs/qa-report.md).
• Archives use ZIP (no Zip64, so each archive < 4 GiB) and ustar TAR.GZ.
• Builds run sequentially.
• No native installers or code signing.

Troubleshooting

License

MIT — see LICENSE.