Support multi-repo projects in ProjectListWorkflow - #199
Merged
Conversation
ProjectListWorkflow already accepted a Repos list, but the Jira lookup it
depends on only ever saw repo short names: GetProjectPRKeys took []string of
short names and keyed its results the same way. Two repos in a project under
different owners collapsed onto one key, so one repo's PRs were fetched from
the other repo's owner (or dropped).
Give the jira package a RepoRef{Owner, Repo} and key the lookup on it. PR
URLs from Jira are now parsed for both owner and repo, matched
case-insensitively (GitHub names are case-insensitive and Jira reports
whatever casing the PR was linked with), and mapped back to the ref as it was
configured so the result can be handed straight to the GitHub API. Parsing is
bounds-checked instead of indexing a split slice blind.
On the workflow side, extract resolveRepoRefs: it keeps the configured order
so each cycle processes repos identically, skips malformed entries, and
collapses duplicates so a repo listed twice is only fetched once.
The docs still told users to create one workflow per repo and share a
SectionTitle; document the Repos list instead, keeping the singular
Owner/Repo example for single-repo projects.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155MTHf62Th1ZDQ6ejhb71y
The config RPC handlers needed no change for multi-repo project lists — GetConfig/UpdateConfig pass Workflows through as []config.RawWorkflow, which already carries Repos, and normalizeWorkflows trims that list for every workflow type — but nothing pinned that down. Add two tests: a multi-repo ProjectListWorkflow submitted through UpdateConfig keeps both repos through validation, the written TOML and the reloaded config, and still builds into a workflow carrying both; and the workflow type registry GetConfig serves advertises Repos for ProjectListWorkflow, which is what makes the web editor offer the field. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0155MTHf62Th1ZDQ6ejhb71y
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Refactor
ProjectListWorkflowto support projects spanning multiple repositories. Previously, each workflow was tied to a single repo viaOwner/Repofields. Now workflows accept aReposlist (e.g.,["owner/repo1", "owner/repo2"]), allowing a single workflow to cover an entire multi-repo project while maintaining backward compatibility with the singularOwner/Repopair.Changes
New
RepoReftype injira/jira.go: Replaces string-based repo identification with a structuredOwner/Repopair. Includes case-insensitive matching vianormalized()and atargetSetfor efficient lookup of configured repos.Enhanced PR URL parsing: Added
parsePRURL()function to extract owner, repo, and PR number from GitHub PR URLs, supporting both github.com and enterprise hosts.Updated
GetProjectPRKeys()signature: Now accepts[]RepoRefinstead of[]string, returningmap[RepoRef][]intto group PRs by their full repo identity rather than short name alone.Improved
processIssues()logic: UsesRepoRefmatching to handle projects with repos sharing the same short name under different owners. PRs linked to repos outside the configured list are properly filtered out.New
resolveRepoRefs()helper inworkflows/project_list.go: Converts configured "owner/repo" entries intoRepoRefstructs, preserving order, dropping malformed entries, and collapsing duplicates.Updated
ProjectListWorkflow.Run(): Walks repos in configured order and fetches PRs for each, ensuring consistent behavior across runs.Documentation updates: Clarified that
ProjectListWorkflownow supports multi-repo projects via theReposlist, with fallback to root-levelReposif omitted. LegacyOwner/Repofields still work for single-repo projects.Test Plan
go test ./...passes — comprehensive unit tests added for:parsePRURL()with standard GitHub URLs, trailing slashes, enterprise hosts, and error casesRepoRefcase-insensitive matching viatargetSetprocessIssues()grouping PRs across repos and filtering unconfigured ownersresolveRepoRefs()handling whitespace, malformed entries, and duplicatesProjectListWorkflowpreserving all repos and declaring no PR requirementsgo build ./...passeshttps://claude.ai/code/session_0155MTHf62Th1ZDQ6ejhb71y