Conversation
WalkthroughBumped Go to 1.25.2 and upgraded numerous dependencies. Added a generated Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
gontzess
changed the title
gontzess
force-pushed
the
task-sdk-upgrade-batch-3
branch
6 times, most recently
from
542c429 to
bca90ac
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@go.mod`:
- Around line 104-107: Update the indirect module versions in go.mod to
remediate known DoS vulnerabilities: change golang.org/x/crypto from v0.34.0 to
at least v0.43.0 (or a later patch) and golang.org/x/oauth2 from v0.26.0 to at
least v0.27.0 (or a later patch); after editing the module lines for
golang.org/x/crypto and golang.org/x/oauth2 run go get ./... or go mod tidy to
resolve and verify the updated transitive dependencies and then run your
tests/build to ensure no breakages.
In `@pkg/config/config.go`:
- Around line 8-25: Remove the unused ConfigurationSchema variable declaration:
delete the block that defines ConfigurationSchema (the field.Configuration{
Fields: ConfigurationFields }) since ConfigurationFields, TokenField and the
exported Config (created via field.NewConfiguration(ConfigurationFields)) are
the actual artifacts used by the generation logic; keep TokenField,
ConfigurationFields and Config intact and ensure no other code references
ConfigurationSchema before committing.
| TokenField = field.StringField( | ||
| "token", | ||
| field.WithDescription("The Segment access token used to connect to the Segment API"), | ||
| field.WithIsSecret(true), | ||
| field.WithRequired(true), | ||
| ) | ||
|
|
||
| ConfigurationFields = []field.SchemaField{ | ||
| TokenField, | ||
| } | ||
|
|
||
| ConfigurationSchema = field.Configuration{ | ||
| Fields: ConfigurationFields, | ||
| } | ||
| ) | ||
|
|
||
| //go:generate go run ./gen | ||
| var Config = field.NewConfiguration(ConfigurationFields) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd / && find . -name "config.go" -path "*/pkg/config/*" 2>/dev/null | head -5Repository: ConductorOne/baton-segment
Length of output: 192
🏁 Script executed:
cat -n pkg/config/config.goRepository: ConductorOne/baton-segment
Length of output: 744
🌐 Web query:
baton-sdk v0.7.4 DefineConfiguration pattern field.NewConfiguration
💡 Result:
In baton-sdk v0.7.4, config.DefineConfiguration(...) (and DefineConfigurationV2) expects a field.Configuration schema object. You build that schema with field.NewConfiguration(...). (pkg.go.dev)
A typical pattern looks like:
import (
"context"
"github.com/conductorone/baton-sdk/pkg/config"
"github.com/conductorone/baton-sdk/pkg/field"
)
var myField = field.StringField(
"my-field",
field.WithDisplayName("My Field"),
field.WithString(func(r *field.StringRuler) *field.StringRuler {
return r.Pattern(`^[a-z0-9_-]{3,32}$`) // regex validation
}),
)
var schema = field.NewConfiguration([]field.SchemaField{
myField,
// ...other fields...
})
func main() {
ctx := context.Background()
_, _, err := config.DefineConfiguration(
ctx,
"my-connector",
newConnectorFunc, // cli.GetConnectorFunc[T]
schema,
)
_ = err
}Key pieces:
field.NewConfiguration([]field.SchemaField{...}, ...)is the schema constructor. (pkg.go.dev)- Regex validation is expressed via
StringRuler.Pattern(...)and attached to aStringFieldusingfield.WithString(...). (pkg.go.dev) config.DefineConfiguration(...)takes thatfield.Configurationas itsschemaargument. (pkg.go.dev)
Citations:
- 1: https://pkg.go.dev/github.com/conductorone/baton-sdk%40v0.7.4/pkg/config
- 2: https://pkg.go.dev/github.com/conductorone/baton-github/pkg/config
- 3: https://pkg.go.dev/github.com/conductorone/baton-sdk%40v0.7.4/pkg/field
- 4: https://pkg.go.dev/github.com/conductorone/baton-sdk%40v0.7.4/pkg/config
🏁 Script executed:
rg "ConfigurationSchema" --type goRepository: ConductorOne/baton-segment
Length of output: 134
🏁 Script executed:
rg "Config\b" pkg/config/config.go -A 2 -B 2Repository: ConductorOne/baton-segment
Length of output: 154
🏁 Script executed:
fd "\.go$" pkg --exec grep -l "DefineConfiguration\|Config" {} \; | head -10Repository: ConductorOne/baton-segment
Length of output: 112
🏁 Script executed:
cat -n pkg/config/gen/gen.goRepository: ConductorOne/baton-segment
Length of output: 325
🏁 Script executed:
rg "\bConfig\b" --type go -l | grep -v vendor | head -5Repository: ConductorOne/baton-segment
Length of output: 138
🏁 Script executed:
rg "config\.Config\|config\\.Config" --type go | grep -v vendor | head -20Repository: ConductorOne/baton-segment
Length of output: 52
Remove unused ConfigurationSchema variable.
The config setup aligns with baton-sdk v0.7.4 patterns: TokenField is correctly marked required and secret, ConfigurationFields array is properly defined, and Config is correctly constructed via field.NewConfiguration() and passed to config.Generate() in gen/gen.go (line 9).
However, ConfigurationSchema (lines 19–21) is defined but never used anywhere in the codebase. It can be safely removed since Config is the actual variable consumed by the generation and configuration logic.
🤖 Prompt for AI Agents
In `@pkg/config/config.go` around lines 8 - 25, Remove the unused
ConfigurationSchema variable declaration: delete the block that defines
ConfigurationSchema (the field.Configuration{ Fields: ConfigurationFields })
since ConfigurationFields, TokenField and the exported Config (created via
field.NewConfiguration(ConfigurationFields)) are the actual artifacts used by
the generation logic; keep TokenField, ConfigurationFields and Config intact and
ensure no other code references ConfigurationSchema before committing.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@go.mod`:
- Line 3: Update the Go toolchain version in go.mod from "go 1.25.2" to "go
1.25.6" to adopt the latest security fixes; open the go.mod file and change the
Go directive (currently "go 1.25.2") to "go 1.25.6", then run `go mod
tidy`/rebuild to ensure module files and vendor state are consistent with the
new toolchain.
Update main.go to use SDK generated config type Segment.
Use `make build` to build to dist/ (already gitignored). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
gontzess
force-pushed
the
task-sdk-upgrade-batch-3
branch
from
69eb9f6 to
8951b1e
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@go.mod`:
- Line 3: The main.yaml GitHub Actions workflow is pinned to Go 1.22.x while
go.mod declares "go 1.25.2"; update main.yaml to either use go-version-file:
'go.mod' (preferred, matching ci.yaml and capabilities.yaml) or set go-version:
1.25.2 explicitly so the workflow aligns with the go.mod declaration; look for
the go-version / go-version-file setting in main.yaml and change it to reference
go.mod or the exact version.
| module github.com/conductorone/baton-segment | ||
|
|
||
| go 1.20 | ||
| go 1.25.2 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Locate Go version settings in CI/config files.
rg -n "go-version|setup-go|GOTOOLCHAIN|toolchain|golang:" -g "*.yml" -g "*.yaml"Repository: ConductorOne/baton-segment
Length of output: 257
🏁 Script executed:
#!/bin/bash
# Find CI configuration files and toolchain specifications
echo "=== GitHub Actions workflows ==="
find .github/workflows -name "*.yml" -o -name "*.yaml" 2>/dev/null | head -20
echo "=== Dockerfile ==="
find . -maxdepth 2 -name "Dockerfile*" 2>/dev/null
echo "=== Tool version files ==="
find . -maxdepth 2 \( -name ".tool-versions" -o -name ".nvmrc" -o -name "go.version" \) 2>/dev/null
echo "=== Root level CI config ==="
ls -la .gitlab-ci.yml .circleci/config.yml .travis.yml 2>/dev/null || echo "No common CI files found"Repository: ConductorOne/baton-segment
Length of output: 323
🏁 Script executed:
#!/bin/bash
# Check GitHub Actions workflows for Go version specifications
echo "=== ci.yaml ==="
cat .github/workflows/ci.yaml
echo ""
echo "=== main.yaml ==="
cat .github/workflows/main.yaml
echo ""
echo "=== capabilities.yaml ==="
cat .github/workflows/capabilities.yaml
echo ""
echo "=== release.yaml ==="
cat .github/workflows/release.yamlRepository: ConductorOne/baton-segment
Length of output: 3557
Fix Go version mismatch in main.yaml workflow.
main.yaml is pinned to Go 1.22.x while go.mod targets 1.25.2. This causes CI drift and potential build failures. Update main.yaml to either use go-version-file: 'go.mod' (like ci.yaml and capabilities.yaml) or explicitly set go-version: 1.25.2.
Workflow mismatch details
- ci.yaml: ✓ Uses
go-version-file: 'go.mod'(aligned) - main.yaml: ✗ Hardcoded to
go-version: 1.22.x(out of sync) - capabilities.yaml: ✓ Uses
go-version-file: 'go.mod'(aligned)
🤖 Prompt for AI Agents
In `@go.mod` at line 3, The main.yaml GitHub Actions workflow is pinned to Go
1.22.x while go.mod declares "go 1.25.2"; update main.yaml to either use
go-version-file: 'go.mod' (preferred, matching ci.yaml and capabilities.yaml) or
set go-version: 1.25.2 explicitly so the workflow aligns with the go.mod
declaration; look for the go-version / go-version-file setting in main.yaml and
change it to reference go.mod or the exact version.
3 participants
Summary
Build Status
go build ./...passes locallyTest plan
Summary by CodeRabbit
New Features
Chores