fix(logs): resolve workflow display name when --repo is set and local lock files exist by Copilot · Pull Request #33656 · github/gh-aw

Copilot · 2026-05-21T00:30:07Z

The logs tool's --workflow-name filter always failed in the MCP server context because GITHUB_REPOSITORY causes --repo to be appended automatically, and the --repo path in logs_command.go bypassed FindWorkflowName entirely — passing the raw workflow ID (e.g. audit-workflows) directly to gh run list --workflow instead of the GitHub Actions display name (e.g. "Agentic Workflow Audit Agent" from the lock file).

Changes

pkg/cli/logs_command.go: When --repo is set, attempt FindWorkflowName resolution against local lock files first. Fall back to normalizeWorkflowID only when local resolution fails (truly cross-repo with no local lock files).

// Before: always skipped FindWorkflowName when --repo was set
workflowName = normalizeWorkflowID(args[0])  // "audit-workflows" → gh run list fails

// After: try local resolution first
if resolved, err := workflow.FindWorkflowName(args[0]); err == nil {
    workflowName = resolved  // "Agentic Workflow Audit Agent" → gh run list succeeds
} else {
    workflowName = normalizeWorkflowID(args[0])  // fallback for remote-only repos
}

pkg/cli/logs_command_test.go: Adds TestLogsCommand_RepoUsesLocalResolutionWhenLockFileExists to cover the case where local lock files are present and --repo is set. The existing TestLogsCommand_RepoBypassesLocalWorkflowResolution (no local files) continues to validate the fallback path.

…files exist When the MCP server sets GITHUB_REPOSITORY (causing --repo to be appended via appendRepoFlagFromEnv), the logs command was bypassing local workflow name resolution entirely and passing the raw workflow ID (e.g. "audit-workflows") directly to `gh run list --workflow`. Because GitHub Actions identifies workflows by their display name (e.g. "Agentic Workflow Audit Agent") rather than the workflow file's base name, this caused `gh run list` to fail with: could not find any workflows named audit-workflows The fix: when --repo is set, attempt FindWorkflowName resolution using local lock files first. If the local lock files are present (i.e. querying the current repo via GITHUB_REPOSITORY), the display name is resolved and passed to the API. If local resolution fails (genuinely cross-repo scenario with no local lock files), fall back to normalizeWorkflowID for the same behaviour as before. Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>

Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>

Copilot

Pull request overview

Fixes gh aw logs workflow filtering when --repo is set (notably in MCP server contexts where GITHUB_REPOSITORY auto-injects --repo) by attempting to resolve the workflow’s GitHub Actions display name from local lock files before falling back to normalized workflow IDs.

Changes:

Update logs command workflow-name resolution to try workflow.FindWorkflowName even when --repo is set, with a fallback to normalizeWorkflowID on resolution failure.
Add a unit test covering the --repo + local lock file present case, and update existing test commentary for the remote/no-local-files path.

Show a summary per file

File	Description
pkg/cli/logs_command.go	Attempts local display-name resolution under `--repo` to make `gh run list --workflow` succeed in MCP server scenarios.
pkg/cli/logs_command_test.go	Adds coverage for `--repo` with local lock files; refines existing test docs for the fallback behavior.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Files reviewed: 2/2 changed files
Comments generated: 2

 				repoOverrideEarly, _ := cmd.Flags().GetString("repo")
 				if repoOverrideEarly != "" {
-					// When --repo is specified, bypass local file-based workflow name
-					// resolution. Normalize the input (strip .md/.lock.yml extensions)
-					// and use it directly as the workflow filter for the remote repo.
+					// When --repo is specified, try local file-based resolution first.
+					// This handles the common case where --repo refers to the current
+					// repository (e.g. set by GITHUB_REPOSITORY in MCP server containers),
+					// so local lock files are available and we can resolve the display name.
 					//
-					// Note: the argument must be a workflow ID (e.g. "test-claude"),
-					// not a display name (e.g. "Test Claude"). Display-name lookup
-					// requires local lock files, which are unavailable for remote repos.
-					workflowName = normalizeWorkflowID(args[0])
-					logsCommandLog.Printf("Using normalized workflow name for remote repo: %s", workflowName)
+					// If local resolution fails (truly remote repo with no local lock files),
+					// fall back to using the normalized workflow ID directly.
+					if resolved, resolveErr := workflow.FindWorkflowName(args[0]); resolveErr == nil {
+						workflowName = resolved
+						logsCommandLog.Printf("Resolved workflow name for repo-overridden query: %s -> %s", args[0], workflowName)
+					} else {
+						workflowName = normalizeWorkflowID(args[0])
+						logsCommandLog.Printf("Using normalized workflow name for remote repo: %s", workflowName)
+					}


+	tmpDir := t.TempDir()
+	workflowsDir := filepath.Join(tmpDir, ".github", "workflows")
+	require.NoError(t, os.MkdirAll(workflowsDir, 0755))
+
+	// Create the markdown file (required by ResolveWorkflowName).
+	// The frontmatter name field is the GitHub Actions display name; the workflow
+	// ID is derived from the filename ("my-test-workflow").
+	require.NoError(t, os.WriteFile(filepath.Join(workflowsDir, "my-test-workflow.md"), []byte("---\nname: My Test Workflow Display Name\n---\n"), 0644))
+
+	// Create a lock file whose display name differs from the workflow ID.
+	// This simulates the real scenario where audit-workflows.lock.yml has
+	// name: "Agentic Workflow Audit Agent" while the ID is "audit-workflows".
+	lockContent := "name: \"My Test Workflow Display Name\"\non: push\n"
+	require.NoError(t, os.WriteFile(filepath.Join(workflowsDir, "my-test-workflow.lock.yml"), []byte(lockContent), 0644))
+
+	t.Setenv("GH_AW_WORKFLOWS_DIR", workflowsDir)
+
+	cmd := NewLogsCommand()
+	cmd.SetArgs([]string{"my-test-workflow", "--repo", "owner/repo"})
+	cmd.SetOut(nil)
+	cmd.SetErr(nil)
+


pelikhan · 2026-05-21T02:32:34Z

@copilot review all comments

Address review feedback: - Add repoIsLocal() helper that checks GITHUB_REPOSITORY env var first, then falls back to GetCurrentRepoSlug(). Local FindWorkflowName is only called when --repo is confirmed to be the current repository, preventing incorrect display-name mapping for cross-repo queries. - Fix test isolation: chdir into tmpDir, set GITHUB_REPOSITORY=owner/repo to match --repo, and pass --output to tmpDir so no files land in the repo root during the test. Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>

Copilot · 2026-05-21T02:39:29Z

@copilot review all comments

Both comments addressed in the latest commit:

Cross-repo concern (logs_command.go:179-194): Added a repoIsLocal(repo string) bool helper that checks GITHUB_REPOSITORY env var first (fast path for MCP server context), then falls back to GetCurrentRepoSlug() (git/gh detection). Local FindWorkflowName is only called when --repo is confirmed to match the current repository. For truly cross-repo queries, normalizeWorkflowID is used as before.
Test isolation (logs_command_test.go:344-365): The test now chdirs into tmpDir (restoring on defer), sets GITHUB_REPOSITORY=owner/repo to match --repo, and passes --output pointing to a subdirectory of tmpDir. This prevents ensureLogsGitignore() and the default output dir from writing into the repo root.

Initial plan

6ef4afe

Copilot AI assigned Copilot and pelikhan May 21, 2026

Copilot started work on behalf of pelikhan May 21, 2026 00:30 View session

Copilot AI linked an issue May 21, 2026 that may be closed by this pull request

[cli-tools-test] logs tool: workflow-name filter fails to find existing workflows #33484

Closed

Copilot AI and others added 3 commits May 21, 2026 00:44

fix: use filepath.Join in test path construction

93d4ccf

Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>

fix: update test markdown frontmatter to match lock file display name

5da7328

Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix workflow-name filter in logs tool to find existing workflows~~ fix(logs): resolve workflow display name when --repo is set and local lock files exist May 21, 2026

Copilot AI requested a review from pelikhan May 21, 2026 00:48

Copilot finished work on behalf of pelikhan May 21, 2026 00:48

pelikhan marked this pull request as ready for review May 21, 2026 01:01

Copilot AI review requested due to automatic review settings May 21, 2026 01:01

Copilot AI reviewed May 21, 2026

View reviewed changes

Copilot started work on behalf of pelikhan May 21, 2026 02:32 View session

Copilot finished work on behalf of pelikhan May 21, 2026 02:40

Merge branch 'main' into copilot/cli-tools-test-fix-workflow-name-filter

c584e35

pelikhan merged commit d372f83 into main May 21, 2026
25 of 26 checks passed

pelikhan deleted the copilot/cli-tools-test-fix-workflow-name-filter branch May 21, 2026 03:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(logs): resolve workflow display name when --repo is set and local lock files exist#33656

fix(logs): resolve workflow display name when --repo is set and local lock files exist#33656
pelikhan merged 6 commits into
mainfrom
copilot/cli-tools-test-fix-workflow-name-filter

Copilot AI commented May 21, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

pelikhan commented May 21, 2026

Uh oh!

Copilot AI commented May 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Copilot AI commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Copilot's findings

Uh oh!

pelikhan commented May 21, 2026

Uh oh!

Copilot AI commented May 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented May 21, 2026 •

edited

Loading