I'm using the latest version of the extension (Run glab --version)
Extension version: 1.36.0
Operating system and version: Fedora 37 Workstation 64 bits
Gitlab.com or self-managed instance? self-managed instance
GitLab version (if self-managed) 16.8.1
(Use the version endpoint, like this: gitlab.my-company.com/api/v4/version)
I have performed glab auth status to check for authentication issues
Summary
glab ci status does not display the current branch pipeline. glab ci status --branch=master does not display the pipeline for the requested branch. It appears that both always display the latest pipeline from the repository.
Environment
OS: Linux 6.0.18-200.fc36.x86_64 x86_64
SHELL: /usr/bin/zsh
TERM: xterm-256color
GLAB: glab version 1.36.0%
Other:
Steps to reproduce
See Summary section.
What is the current bug behavior?
Displays the pipeline of another branch and not the current or requested branch (--branch). See Summary section for details.
What is the expected correct behavior?
Displays the pipeline for the current or requested branch (--branch).
✓
5 of 5 checklist items completed
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
GraphQL error: The resource that you are attempting to access does not exist or you don't have permission to perform this action
No child items are currently open.
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@dwouglas I'm not able to reproduce this on GitLab.com - are you still able to reproduce this behavior?
~/Dev/GitLab/cli on phikai-trigger-docs-typo ❯ glab ci status took 5s✘ No pipelines running or available on branch: phikai-trigger-docs-typoGET https://gitlab.com/api/v4/projects/gitlab-org/cli/repository/commits/phikai-trigger-docs-typo: 404 {message: 404 Commit Not Found} ~/Development/GitLab/cli on phikai-trigger-docs-typo ❯ glab ci status --branch=main(success) • 00m 47s release windows_installer(success) • 10m 48s release release_test(success) • 01m 46s test build_windows(success) • 03m 46s test run_tests: [1.21](success) • 01m 36s test code_navigation(success) • 01m 56s test lint(success) • 01m 17s test license_scanning(success) • 00m 15s test secret_detection(success) • 00m 40s test gemnasium-dependency_scanning(success) • 00m 42s test semgrep-sast(success) • 00m 39s test nodejs-scan-sasthttps://gitlab.com/gitlab-org/cli/-/pipelines/1222545208SHA: 2de2d082c8e11be778669b699847c573d40f9754Pipeline State: success? Choose an action: [Use arrows to move, type to filter] View Logs Retry> Exit
It took me to the left pipeline, when it should have taken me to the right pipeline:
I did some more testing, and it seems that when the last pipeline is Skipped, it shows the wrong pipeline.
After running the pipeline from the master branch, which was Skipped and became Passed, the glab ci status and glab ci status --branch=master commands started to correctly report the pipeline address.
@dwouglas have you tried with 1.52.0? In case it still doesn't work, I've added debug output in !1847 (merged) which you can try to see what exactly is being detected.
@abitrolly I tested the !1849 (merged) version and it still has the same problem. Please see if I did it right and note that it continues to point to the wrong pipeline that I sent in the image above.
╭─ ~/projetos/glab main ╰─ git remote -vv origin https://gitlab.com/gitlab-org/cli.git (fetch)origin https://gitlab.com/gitlab-org/cli.git (push)╭─ ~/projetos/glab main ╰─ git pull Already up to date.╭─ ~/projetos/glab main ╰─ glab mr checkout 1849╭─ ~/projetos/glab fix-fork-status ╰─ echo $GOPATH ; ll $GOPATH/tmp/glablsd: /tmp/glab: No such file or directory (os error 2).╭─ ~/projetos/glab fix-fork-status╰─ go versiongo version go1.23.4 linux/amd64╭─ ~/projetos/glab fix-fork-status ╰─ go install ./cmd/glab (omitted)╭─ ~/projetos/glab fix-fork-status ╰─ $GOPATH/bin/glab versionCurrent glab version: DEV╭─ ~/projetos/glab fix-fork-status ╰─ z util╭─ ~/xxx-utilitarios master╰─ $GOPATH/bin/glab ci status? Choose an action: [Use arrows to move, type to filter] View logs Retry> Exithttps://git.xxx/xxx/xxx-utilitarios/-/pipelines/893352SHA: 319dec0b84b69d73789f6ea40eb44e4f5acc6a3dPipeline state: skipped
I am almost certain the /commits endpoint will return the wrong pipeline. Almost.
So, what is (probably) going on here is that the same commit SHA is present in different branches. And at some point GitLab uses commit SHA instead of branch name to request commit info, and if the nonmain branch pipeline was triggered later for the same SHA, it will appear in last_pipeline field of the SHA.