[FEAT]: Add team command group - #727
Conversation
| var err error | ||
|
|
||
| spinErr := bkIO.SpinWhile(f, "Loading teams information", func() { | ||
| teams, _, err = f.RestAPIClient.Teams.List(ctx, f.Config.OrganizationSlug(), nil) |
There was a problem hiding this comment.
Any concerns about not paginating here? I'm not sure how many teams we return per page, but I'm guessing sooner or later we will come across someone who has hundreds of them.
| Description: current.Description, | ||
| Privacy: current.Privacy, | ||
| IsDefaultTeam: current.Default, | ||
| MembersCanCreatePipelines: false, |
There was a problem hiding this comment.
Claude flagged the fact that every time someone updates a team, it's going to set members_can_create_pipelines: false even if the current setting for that team is true. "Balderdash," said I. "Prove it!" So we looked at go_buildkite, where it turns out that the Team struct doesn't include all the fields that the API returns, including MembersCanCreatePipelines. And then looking upstream at the API in Team::Updater and how it would handle this, it looks like it would in fact apply the false flag and change the setting unexpectedly. We'd need to fix this in go_buildkite and then here do MembersCanCreatePipelines: current.MembersCanCreatePipelines,
If this makes sense to you, I can throw the PR at go_buildkite and then add a commit to this.
There was a problem hiding this comment.
I think false is a sensible default? It's definitely safer than true and would still allow for creation of the team but with safeguards in place.
There was a problem hiding this comment.
Discussed in Slack - we still need to fix go_buildkite to avoid us forcibly changing this setting when we update teams. That'll be a separate task.
341f59d to
d4f894d
Compare
There was a problem hiding this comment.
The latest merge from main left the branch unbuildable. I left three blockers for the parse, module, and callback-signature failures reported by CI, plus one non-blocking pagination edge case.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 8503, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
About buildsworth
Model: gpt-5.6-sol with xhigh thinking.
How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.
Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. To let it approve, grant L2 approval by mentioning @buildsworth-bk (see L2 approval grant):
- L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
- L2 — Standard risk (new UI, additive API fields, refactors). Approved only with an L2 grant; otherwise comment-only.
- L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.
There was a problem hiding this comment.
The three build/compile blockers from the last pass are fixed. The pagination edge case is still open, and I left three non-blocking CLI edge cases inline.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 8563, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
Previous concerns have been addressed.
There was a problem hiding this comment.
All prior buildsworth concerns are addressed in the current revision, and I found no new issues. This adds destructive and permission-changing team operations, so this remains comment-only.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 8582, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
|
|
||
| if len(all) > limit { | ||
| hasMore = true | ||
| } |
There was a problem hiding this comment.
Minor: Could we only set hasMore after confirming another result exists? When the total is exactly equal to --limit and the final page is full, this reports Showing 2+ teams even though page 2 is empty. Fetching one extra result or page would distinguish an exact boundary from truncated output. A test where the total equals both --limit and --per-page should cover it.
There was a problem hiding this comment.
I left one non-blocking pagination validation edge case. The destructive and permission-changing team operations keep this comment-only.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 9503, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
| } | ||
|
|
||
| func (c *ListCmd) Validate() error { | ||
| if c.PerPage < 1 { |
There was a problem hiding this comment.
Non-blocking: The REST API caps per_page at 100, but this accepts larger values. For example, with --per-page 101 --limit 200, the server returns 100 teams, listTeams treats that as a partial page, and stops after page 1 with hasMore == false. Could we reject values above 100 (or clamp the value) so pagination remains correct?
There was a problem hiding this comment.
Still open — Validate continues to accept values above the API’s 100-item maximum, so the server-side cap can still make pagination stop after the first page.
There was a problem hiding this comment.
Still open — Validate still accepts --per-page values above 100, so the server cap can make the first page look partial and stop pagination.
There was a problem hiding this comment.
The existing --per-page validation concern is still open; I found no new issues in this revision. The destructive and permission-changing team operations keep this comment-only.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 9513, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
There was a problem hiding this comment.
One new team-permission blocker is inline, along with a non-blocking text-list gap. The existing --per-page validation concern remains open.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 9715, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
| Privacy: c.Privacy, | ||
| IsDefaultTeam: c.Default, | ||
| DefaultMemberRole: c.DefaultMemberRole, | ||
| MembersCanCreatePipelines: c.MembersCanCreatePipelines, |
There was a problem hiding this comment.
Blocking: buildkite.CreateTeam serializes every permission boolean (none use omitempty), so omitting MembersCanCreateSuites and MembersCanCreateRegistries here sends both as false. The API defaults both to true for a minimal team, so bk team create silently disables those permissions. Could we expose or populate the remaining permission fields and cover the request body?
| } | ||
|
|
||
| return output.Table( | ||
| []string{"Name", "Slug", "Privacy", "Default"}, |
There was a problem hiding this comment.
Non-blocking: The other resource lists (cluster, queue) include the ID needed by their follow-up commands. This text table omits team.ID, while view, update, and delete accept only a team UUID, so a user cannot carry a listed row into those commands. Could we include an ID column?
Description
Adds support for group of
teamcommands, as available in go-buildkiteChanges
team {create,delete,list,update,view}main.goto supportTesting
go test ./...)go fmt ./...)