bazel-contrib / bazel-contrib/rules_go
Stamping a variable in vendored library requires some kinda unexpected tweaks
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 762
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 12
Description
### What version of rules_go are you using?
`v0.25.1`
### What version of gazelle are you using?
`v0.22.3`
### What version of Bazel are you using?
`4.0.0`
### Does this issue reproduce with the latest releases of all the above?
Yes
### What operating system and processor architecture are you using?
linux/amd64
### Any other potentially useful information about your toolchain?
### What did you do?
I want to stamp a variable from an external dependency, `github.com/reddit/baseplate.go/log.Version` ([src](https://github.com/reddit/baseplate.go/blob/c1598b6e96dec063ba36881a43b86200e46825c8/log/log.go#L43)). We use vendoring for all our external dependencies.
When using `go build` to do the stamping, this works, as expected:
```
go build -mod=vendor -ldflags "-X github.com/reddit/baseplate.go/log.Version=$(git rev-parse HEAD)"
```
But when trying to do it in my `go_binary` rule, this does not work:
```
x_defs = {
"github.com/reddit/baseplate.go/log.Version": "{STABLE_GIT_COMMIT}",
},
```
I have to add `/vendor/` prefix to make it work:
```
x_defs = {
"/vendor/github.com/reddit/baseplate.go/log.Version": "{STABLE_GIT_COMMIT}",
},
```
I'm not sure if this is fixable or not. If it is not, then I think it's at least worth mentioning in the doc, as it took me a while to figure out how to stamp it correctly.
Contributor guide
Research direction
Reproduce the stamping case with rules_go v0.25.1, Gazelle v0.22.3, Bazel 4.0.0, and vendored dependencies. Start with the go_binary x_defs configuration and the Version variable in log/log.go from the linked baseplate.go source, then compare the unprefixed and vendor-prefixed paths. Done means stamping works consistently or the required vendor-path behavior is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100