Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add multi-remote fork topology and non-candidate ref test fixtures to ears-manager self-host suite

Open
  • Is something wrong?
#293 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
53/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
git, go
Domain
devtools, testing

Research direction

Start with ears-manager/internal/cli/selfhost_test.go and the approvedRepositoryConfig and evaluateCandidate paths in ears-manager/internal/cli/state.go. Read the existing self-host fixtures and identify how they create repositories, refs, and remotes; then add cases for malformed non-candidate refs, fork and upstream remotes, and a checked-out local main branch. Run the named Go test command from the issue; done means all three regressions are covered and pass.

Written by the indexing model from the issue text.

Description

blocked component:ears-manager ready-for-triage

What happened

During the implementation of Issue #255 on PR #289 (https://github.com/redhat-et/ProtoBot/pull/289), the fix agent implemented approvedRepositoryConfig in ears-manager/internal/cli/state.go to anchor default-branch repository configuration to trusted Git refs. In Review Run 4 (workflow run 38657564178), the Review Agent advised failing closed on DecodeFields errors in evaluateCandidate (finding A23). The fix agent implemented this in commit 4bdd2dc, and all existing unit tests in selfhost_test.go passed.

However, in formal code reviews (https://github.com/redhat-et/ProtoBot/pull/289#pullrequestreview-3339396348, https://github.com/redhat-et/ProtoBot/pull/289#pullrequestreview-3343603387), maintainer John Strunk identified three blocking defects:

  1. B2 (Unrelated refs break check): Any clone with fetch-depth: 0 containing an unrelated feature or wip branch with invalid YAML crashed ears-manager check with exit 6 git.read_failed because approvedRepositoryConfig decoded all refs before filtering by candidate branch name.
  2. B3 (Fork config self-approval): In a standard multi-remote fork clone (origin pointing to an untrusted fork with its own main, upstream pointing to canonical redhat-et/ProtoBot), evaluateCandidate accepted a candidate remote if its URL matched canonical_remote read from that same candidate's project.yaml. Because candidates were sorted alphabetically by remote name, origin was evaluated before upstream, allowing a fork's main branch to self-declare canonical and supply the baseline.
  3. B4 (Checked-out main cannot resolve): In a local clone with main checked out and no remote-tracking refs, approvedRepositoryConfig skipped refs/heads/<HEAD>, causing check to fail with project.default_branch_unresolved.

PR #289 was closed unmerged after 9 iterations failed to resolve these edge cases without breaking existing tests.

What could go better

The root cause of these three defects escaping autonomous review and automated testing was a gap in ears-manager's test fixtures. selfhost_test.go only exercised isolated repositories with a single local branch or a single remote, and all test repositories contained strictly well-formed YAML. When the Review Agent advised failing closed on decode errors, the agent had no fixture to reveal that blanket fail-closed behavior would break repositories with non-candidate branches.

Had the test suite included multi-remote fixtures, non-candidate refs with invalid YAML, and local-only checkouts of main, the Code Agent and Fix Agent would have caught these regressions immediately during local go test runs prior to submission.

Proposed change

In ears-manager/internal/cli/selfhost_test.go, add dedicated regression and topology tests:

  1. TestSelfHostingUnrelatedRefMalformedConfigIgnored: Create a test repository with a valid default branch and an unrelated non-candidate branch (e.g., refs/heads/wip-corrupted) containing malformed YAML in .protobot/project.yaml. Verify that ears-manager check ignores the malformed non-candidate ref and successfully validates against main without returning git.read_failed.
  2. TestSelfHostingForkCloneUpstreamCanonicalPriority: Configure a multi-remote fixture with remote origin pointing to a fork whose main branch declares its own fork URL as canonical_remote, and remote upstream pointing to canonical redhat-et/ProtoBot. Verify that approvedRepositoryConfig resolves the baseline from upstream and rejects or ignores origin's self-declaration.
  3. TestSelfHostingCheckOnCheckedOutDefaultBranchSucceeds: Check out main directly in a clean local repository without configured remote-tracking refs and verify that ears-manager check resolves main as the default branch without throwing project.default_branch_unresolved.
  4. Update ears-manager/internal/cli/state.go to filter candidate ref names prior to decoding Git blobs, and ensure candidate remote evaluation anchors to verified upstream remotes.

Validation criteria

  1. Running go test ./ears-manager/internal/cli -v -run 'TestSelfHosting(UnrelatedRef|ForkClone|CheckOnCheckedOut)' fails when executed against PR #289's head commit (5c45cea4695d1f7d94130e10098bfeed660b9475), catching findings B2, B3, and B4.
  2. Running the same test suite against an updated implementation that filters candidate refs before decoding and prioritizes canonical remotes passes cleanly.

Generated by retro agent from https://github.com/redhat-et/ProtoBot/pull/289

Dominant language
Go
Stars
6
Forks
8
Avg merge
1d 5h
Merged PRs (30d)
84

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from redhat-et/ProtoBot

All issues in redhat-et/ProtoBot

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.