Conversation
📝 WalkthroughWalkthroughThis PR removes the fallback-based project name loading mechanism ( Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
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)
No actionable comments were generated in the recent review. 🎉 🧹 Recent nitpick comments
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.5.0)level=warning msg="[linters_context] running gomodguard failed: unable to read module file go.mod: current working directory must have a go.mod file: if you are not using go modules it is suggested to disable this linter" Comment |
Description
Coderabbit suggested this issue in #1914 (comment)_
The "too many projects error" is only returned by playground, and playground has its own implementation of
RemoteProjectName, so coderabbit wasn't entirely correct. However, this function is reachable if the project name is not available from the loader, or in the flagset, and it is potentially confusing in that it returns the first project out of a seemingly unsorted list retrieved from the cd s3 bucket. This function has been marked deprecated for the base byoc client for a while now, so this PR aims to rip it out by taking the following steps:LoadProjectNameWithFallbackand load project name directly from the loaderCLIInterfacemethodLoadProjectNameWithFallbacktoLoadProjectName, but I did not inline it, because it is still used for mocking in tests.Linked Issues
Checklist
Summary by CodeRabbit
Release Notes