Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The "owner" argument for flux bootstrap gitlab (probably others too) does not make sense if URL includes groups/subgroups #3817

Open
aleksandaratanasov opened this issue Apr 19, 2023 · 10 comments · May be fixed by #4899
Open

The "owner" argument for flux bootstrap gitlab (probably others too) does not make sense if URL includes groups/subgroups #3817

aleksandaratanasov opened this issue Apr 19, 2023 · 10 comments · May be fixed by #4899

Comments

@aleksandaratanasov
Copy link

The research institute I am working for has its own GitLab instance. My team has its own group and inside we have subgroups and what not. The repository I would like to use has the following URL (placeholders used due to privacy):

https://gitlab.example.com/institute/department/research-group/cloud-computing/administration/k8s-playground.git

As you can see the structure is nested:

  • institute - the name of the institute
  • department - the name of the department with focus on specific research area(s)
  • research-group - the name of the team with focus on specific research area(s)
  • cloud-computing - a sub-group of the my team's group I have created (I am the owner) to put everything related to cloud in it
  • administration - a sub-group of the cloud-computing group for admin tasks (e.g. GitOps for managing the infrastructure)
  • k8s-playground - the actual project that will be used by flux to sync the Kubernetes (in my case an Ubuntu 22.04 Server with microk8s; for setting up flux to work with microk8s see here )

I am quite new to GitOps and Kubernetes in general but I do believe that flux is rather confusing when it comes to anything that is not in the form of

https://gitlab.example.com/USER/REPOSITORY.git

The URL I have used at the beginning needs to be split into chunks that, given the name of the argument --owner, is anything but helpful. It took me half an hour trying to figure out what's going on:

flux bootstrap gitlab --hostname=https://gitlab.example.com --repository=k8s-playground --branch=main --path=./clusters/playground/ --token-auth --owner=institute/department/research-group/cloud-computing/administration

Notice the absence of trailing/leading /, which is an extra thing the user needs to consider not to mention the absence of .git suffix. I do realize that internally a lot of concatenation is going on and this is how I managed to figure out what to put where.

However in the end --owner=institute/department/research-group/cloud-computing/administration is not really the owner but rather a nested structure.

I would suggest to rename the owner to something like url-path or similar. Best would be remove that completely and just go with the full URL for the --repository argument since most people are familiar with that anyway. I would further suggest to remove the requirement to discard the .git suffix and remove --hostname:

flux bootstrap gitlab --repository=https://gitlab.example.com/institute/department/research-group/cloud-computing/administration/k8s-playground.git --branch=main --path=./clusters/playground/ --token-auth

In the end hostname can be extracted inside flux itself (plenty of regexes out there for doing that).
@simonfelding
Copy link

fully agree. it's really hard to figure out whats going on when the variable names are so blatantly incorrect and the output from the CLI is misleading too.

@nagyv
Copy link
Contributor

nagyv commented Apr 4, 2024

I opened an issue in the GitLab issue tracker to get GitLab involved in improving the UX. I recommend to continue the discussion there, and finally create an RFC here.

@nagyv
Copy link
Contributor

nagyv commented Jun 13, 2024 •
edited
Loading

@simonfelding @aleksandaratanasov @razvanphp @elehcim We discussed at GitLab the flux bootstrap gitlab command arguments / UX, and came up with the following proposal. I'd like to ask for your feedback about it:

We recommend two GitLab specific flags:

  • Gitlab hostname: --hostname
  • Project path (group(s) + project): --project-path
    • example: gitlab-org/gitlab
    • the last part is always the project

Together with implementing the above changes, we recommend to:

  • drop the --personal flag
  • change --private to –-visibility: public | internal | private
  • when running from a gitlab project checkout directory, the --hostname and --project-path should default to those of the current repo

Together with the above we discussed that --path and -–project-path might be confusing. Still, we recommend going forward with both flags as there is a description with usage, and both names are typical across GitLab.

Please, let me know what you think!

@elehcim
Copy link

elehcim commented Jun 23, 2024

I think it's a great proposal. Thanks

@simonfelding
Copy link

simonfelding commented Jun 23, 2024 via email

@nagyv
Copy link
Contributor

nagyv commented Jun 24, 2024

It's good but it would be even greater if it supported using a pre-existing repo (all it should do is set up the token).

@simonfelding Did you meant that when running from a gitlab project checkout directory, the --hostname and --project-path should default to those of the current repo? I like this idea! Thanks!

@simonfelding
Copy link

simonfelding commented Jun 24, 2024 via email

@stefanprodan
Copy link
Member

The bootstrap command only works with setting up a new project (that doesn't already exist).

Never heard this before from GitLab users, Flux bootstrap should detect if a repo exists and uses it. How did you come to this conclusion?

@makkes
Copy link
Member

makkes commented Jun 25, 2024

The bootstrap command only works with setting up a new project (that doesn't already exist).

This is wrong! The bootstrap gitlab command works just fine with a pre-existing project. I just did exactly that.

@simonfelding
Copy link

simonfelding commented Jun 25, 2024 via email

@nagyv nagyv mentioned this issue Jun 28, 2024
Merged
nagyv added a commit to nagyv/flux2 that referenced this issue Jul 20, 2024
@nagyv
Introduce projectPath argument for GitLab bootstrap
9b68790 
Deprecates the `owner` and `repository` arguments.

Closes: fluxcd#3817
Signed-off-by: Viktor Nagy <[email protected]>
@nagyv nagyv linked a pull request Jul 20, 2024 that will close this issue
Open
nagyv added a commit to nagyv/flux2 that referenced this issue Jul 20, 2024
@nagyv
Introduce projectPath argument for GitLab bootstrap
ec9f23d 
Deprecates the `owner` and `repository` arguments.

Closes: fluxcd#3817
Signed-off-by: Viktor Nagy <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Gitlab bootstrap project path nagyv/flux2
6 participants
@nagyv @makkes @elehcim @aleksandaratanasov @stefanprodan @simonfelding