glab
glab copied to clipboard
Incorrect assignees with both GitLab.com and self-hosted accounts
Description
Hello, thanks for your work on glab
!
I encountered a (new?) bug which may be related to #468, but I think this is rather different one on the backend.
First, I have both GitLab.com and a self-hosted instance with different handles (astrochun and cly, respectively).
For self-hosted repos, I gitlab auth login
and that's properly configured. I recently started some testing work on GitLab.com to ensure I have the proper CI/CD in place (our self-hosted instance currently can't support GitLab Pages). I also gitlab auth login
for GitLab.com and that seem to work as intended (e.g., Can create issues and MR).
The issue I'm encountering is that when I provide the assignees metadata for my GitLab.com account, it seems to send the wrong handle ("cly") over to the GitLab API (should send "astrochun"). This happens for both issues and MRs.
Here's a snapshot of what I see from glab
.
But if you go to the repo in question, you will see that this accidentally assign it to someone else with the "cly" handle. Issue: https://gitlab.com/astrochun/mkdocstrings-page/-/issues/2 MR: https://gitlab.com/astrochun/mkdocstrings-page/-/merge_requests/2
I believe this is occurring because one of my glab alias
has --assignee cly
set. Yet, it seems that when I try to override through the glab
interaction, it still sends cly.
Expected Behavior vs Actual Behavior
It should send "astrochun" given that was specified in the selection menu instead of the initial input.
Possible Fix
Steps to Reproduce
- Type this '...'
- View the output '....'
- See error
Logs
Your Environment
- Version used (Run
glab --version
): 1.18.1 - Operating System and version:
MacOS: 10.15.7
python
: 3.10.0
This issue has been automatically marked as stale because it has not had recent activity. We haven't had the time to address it yet, but we want to keep it open. This message is just a reminder for us to help triage issues.