glab repo clone cannot filter out shared projects
Checklist
-
I'm using the latest version of the extension (Run glab --version
)- Extension version:
1.46.1 (2024-09-10)
- Extension version:
-
Operating system and version: - MacOS 14.6.1 (ARM, but I've replicated this on an x64 MacOS as well)
-
Gitlab.com or self-managed instance? - gitlab.com
-
I have performed glab auth status
to check for authentication issues
Summary
The default behaviour of glab repo clone
is supposed to ignore any shared projects, when cloning from a group. From the documentation:
-S, --with-shared Include projects shared to this group. Default is false. Used with the --group flag.
However, regardless of whether the parameter is omitted or passed as --with-shared=false
, glab repo clone
always clones projects that are shared to the group.
Environment
- OS: Darwin 23.6.0 arm64
- SHELL: /bin/zsh
- TERM: xterm-256color
- GLAB: Current glab version: 1.46.1 (2024-09-10)%
Steps to reproduce
A publicly available group that this can be replicated with is gitlab-com/marketing
. If we ignore subgroups, it has 3 projects directly under it (2 archived/"inactive"), and 1 shared project (tfir-gitlab-media-collaboration
).
Run:
glab repo clone --include-subgroups=false --paginate --group gitlab-com/marketing
or, with --with-shared=false
:
glab repo clone --with-shared=false --include-subgroups=false --paginate --group gitlab-com/marketing
And it still clones the shared project, tfir-gitlab-media-collaboration
.
What is the current bug behavior?
glab repo clone
clones shared projects, regardless of whether I try to use the "default behaviour" or pass --with-shared=false
explicitly.
What is the expected correct behavior?
glab repo clone
will not clone shared projects if I pass in --with-shared=false
.
I don't know if the default behaviour should be fixed, as it essentially would be a breaking change.
Relevant logs and/or screenshots
gitlab/test/clone1
$ glab repo clone --with-shared=false --include-subgroups=false --paginate --group gitlab-com/marketing
Cloning into 'onboarding'...
<snip>
Cloning into 'tfir-gitlab-media-collaboration'...
<snip>
Cloning into 'online-growth'...
<snip>
Cloning into 'content-marketing'...
<snip>
✓ gitlab-com/marketing/onboarding
✓ arnieswap/tfir-gitlab-media-collaboration
✓ gitlab-com/marketing/online-growth
✓ gitlab-com/marketing/content-marketing
Possible fixes
One part of the problem is that we're only update the --with-shared
option if it is set to true:
https://gitlab.com/gitlab-org/cli/-/blob/main/commands/project/clone/repo_clone.go?ref_type=heads#L191-L193
... even though the GitLab API treats with_shared=true
as the default (source: https://docs.gitlab.com/ee/api/groups.html#list-a-groups-projects), so the --with-shared
parameter is currently not doing anything.
Since it might be possible that people are now "relying" on this behaviour to pull shared projects by default, it probably also would make sense to change the default value of opts.WithShared
to true
, and then check if it's set to false
by the user.