Skip to content

Conversation

runningcode
Copy link
Contributor

@runningcode runningcode commented Sep 10, 2025

Summary

Implements EME-232 to automatically detect base_repo_name for build uploads when not explicitly provided by the user.

Changes

  • Added git_repo_base_repo_name() function in src/utils/vcs.rs that:
    • Fetches the first available git remote from the repository
    • Extracts the repository name using existing get_repo_from_remote() function

🤖 Generated with Claude Code

Closes https://linear.app/getsentry/issue/EME-232/sentry-cli-provide-default-value-for-base-repo-name-if-user-doesnt

Automatically detect base_repo_name for build uploads when not explicitly provided.
The implementation fetches the first available git remote and extracts the repository
name, following the same pattern as existing VCS auto-detection features.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
@runningcode runningcode requested review from szokeasaurusrex and a team as code owners September 10, 2025 09:24
Copy link

linear bot commented Sep 10, 2025

Copy link
Member

@szokeasaurusrex szokeasaurusrex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just one question about picking the branch.

Also, another design question: does it really make sense to fall back to the first branch if origin is missing? I think it is sensible if there is only one remote configured, but if there are multiple remotes, and none of them are origin, it might instead be a good idea to not set a remote and instead print a warning.

Although, as this is likely an edge case, I think it is also ok to stick with the current implementation, just wanted to ask whether you considered this already :)

return Ok(None);
}

// Prefer "origin" remote if it exists, otherwise use the first one
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also consider checking the upstream remote of the current branch? If so, would that take precedence over origin or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good point. I checked back with our team. We should prefer upstream over origin for forked workflows. I'll update this in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up PR on this: #2737

@runningcode
Copy link
Contributor Author

runningcode commented Sep 10, 2025

That's a good question about falling back to the first branch in the list if there is no origin.
So the options here are

  1. guessing wrong
  2. guessing nothing

Either way, the outcome is the same the integration doesn't work. Guessing using the first one in the list might be right some of the time so it is better to do that than to return nothing.

If the integration doesn't work (either if we returned nothing or guessed wrong) the user will need to override the value.

So we'll stick with the current implementation of guessing the first one in the list.

@runningcode runningcode merged commit 3c48dab into master Sep 10, 2025
23 checks passed
@runningcode runningcode deleted the no/eme-232-sentry-cli-provide-default-value-for-base-repo-name branch September 10, 2025 14:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants