Skip to content

Conversation

jakobht
Copy link
Member

@jakobht jakobht commented Sep 1, 2025

What changed?

Added a new cadence-releasetagger tool and corresponding make tag-release target that generates git tag commands for both the main repository and all Go submodules.

The tool automatically discovers all Go modules in the repository and creates appropriately namespaced tags:

  • Main repository: v1.2.3
  • Submodules: cmd/server/v1.2.3, common/archiver/gcloud/v1.2.3, etc.

Usage:

# Generate tag commands for version v1.2.3
make tag-release VERSION=v1.2.3

# Then execute the generated commands:
git tag v1.2.3 cmd/server/v1.2.3 ...
git push origin v1.2.3 cmd/server/v1.2.3 ...

Why?

This makes it easy to tag all submodules so we can refer to them with proper versioning.

Go's module system supports both main and submodule tags for proper semantic versioning in repos with more than one module. See Go Modules Reference for details on submodule versioning.

How did you test it?

Tested with sample versions: ./cadence-releasetagger v1.5.0-test
Verified output includes both main and submodule tags

Example output:

git tag v1.5.0-test cmd/server/v1.5.0-test common/archiver/gcloud/v1.5.0-test service/sharddistributor/store/etcd/v1.5.0-test
git push origin v1.5.0-test cmd/server/v1.5.0-test common/archiver/gcloud/v1.5.0-test service/sharddistributor/store/etcd/v1.5.0-test

Potential risks

Very low risk - this is a code generation tool that only outputs git commands. It doesn't execute anything automatically.

Release notes

Documentation Changes

- Creates both main repository tags and submodule tags
- Integrates with existing make-based build system
- Automatically discovers all Go submodules
- Provides consistent tagging across mono-repo
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there's a way to tell git to ignore executable files by default

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooops - deleted and added to gitigonore

Comment on lines +17 to +31
for _, line := range strings.Split(goListOutput, "\n") {
parts := strings.Split(line, "\t")
if len(parts) != 2 {
continue
}
modulePath, moduleDir := parts[0], parts[1]

if strings.HasPrefix(modulePath, mainModule+"/") {
relPath, err := filepath.Rel(root, moduleDir)
if err != nil {
return "", fmt.Errorf("error getting relative path for %s: %v", moduleDir, err)
}
tags = append(tags, fmt.Sprintf("%s/%s", relPath, version))
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

frustratingly hard in bash, yea. tbh I think minor go scripts like this are reasonable, and they have the extreme benefit of being far more likely to be cross-platform by accident.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO anything that has branching, loops or string processing should not be written in bash - it becomes impossible to read so fast.

}
version := os.Args[1]

cmd := exec.Command("go", "list", "-m", "-f", "{{.Path}}\t{{.Dir}}", "all")
Copy link
Member

@Groxx Groxx Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is probably fine to use, but as an fyi: this can probably trigger downloads and be kinda slow. might want to limit it to like 1s and give up (and print stderr) if it takes too long.

(it does not appear to need the modules to be downloaded, but it could still trigger e.g. a go-toolchain download-and-install during which it'll just hang silently)

that said: I suppose this probably is the canonically correct way to get this info 🤔 tags need to be based on the relative path, not whatever the module names happen to be, so 👍 https://go.dev/doc/modules/managing-source#multiple-module-source

Comment on lines +541 to +544
BINS += cadence-releasetagger
cadence-releasetagger: $(BINS_DEPEND_ON)
$Q echo "compiling cadence-releasetagger with OS: $(GOOS), ARCH: $(GOARCH)"
$Q go build -o $@ cmd/tools/releasetagger/main.go
Copy link
Member

@Groxx Groxx Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you do end up using x/mod/semver, this is likely better as

$(BIN)/releasetagger: internal/tools/go.mod $(wildcard internal/tools/releasetagger/*) | $(BIN)
	$(call go_build_tool,./releasetagger)

as that way it'll rebuild on go / mod changes.

as long as it's just stdlib it doesn't really matter what builds it though.

Copy link
Member

@Groxx Groxx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete the binary for sure, but otherwise LGTM with only minor stuff that may be worth doing. good to go either way 👍

fmt.Println("Usage: go run main.go <version>")
os.Exit(1)
}
version := os.Args[1]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably worth doing a https://pkg.go.dev/golang.org/x/mod/semver#IsValid check to make sure it's a valid semver?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants