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

[BUG] - Nebari init fails when using a GitLab repo for the GitOps approach #2268

Open
marcelovilla opened this issue Feb 21, 2024 · 5 comments · May be fixed by #2269
Open

[BUG] - Nebari init fails when using a GitLab repo for the GitOps approach #2268

marcelovilla opened this issue Feb 21, 2024 · 5 comments · May be fixed by #2269
Labels
area: nebari-cli type: bug 🐛 Something isn't working

Comments

@marcelovilla
Copy link
Member

Describe the bug

When running nebari init and specifying a GitLab repo, the command fails with the following error:

╭─────────────────────────────── Traceback (most recent call last) ────────────────────────────────╮
│ /usr/local/bin/nebari:8 in <module>                                                              │
│                                                                                                  │
│   5 from nebari.__main__ import main                                                             │
│   6 if __name__ == '__main__':                                                                   │
│   7 │   sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])                         │
│ ❱ 8 │   sys.exit(main())                                                                         │
│   9                                                                                              │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/nebari/__main__.py:8 in main                             │
│                                                                                                  │
│    5                                                                                             │
│    6 def main():                                                                                 │
│    7 │   cli = create_cli()                                                                      │
│ ❱  8 │   cli()                                                                                   │
│    9                                                                                             │
│   10                                                                                             │
│   11 # get the click object from the typer app so that we can autodoc the cli                    │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/typer/main.py:328 in __call__                            │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/typer/main.py:311 in __call__                            │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/click/core.py:1130 in __call__                           │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/typer/core.py:778 in main                                │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/typer/core.py:216 in _main                               │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/click/core.py:1655 in invoke                             │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/click/core.py:920 in make_context                        │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/click/core.py:1378 in parse_args                         │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/click/core.py:2360 in handle_parse_result                │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/click/core.py:2322 in process_value                      │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/typer/main.py:994 in wrapper                             │
│                                                                                                  │
│ /usr/local/lib/python3.11/site-packages/_nebari/subcommands/init.py:797 in guided_init_wizard    │
│                                                                                                  │
│   794 │   │   │   │   qmark=qmark,                                                               │
│   795 │   │   │   ).unsafe_ask()                                                                 │
│   796 │   │   │                                                                                  │
│ ❱ 797 │   │   │   inputs.repository = repo_url.format(                                           │
│   798 │   │   │   │   git_provider=git_provider, org_name=org_name, repo_name=repo_name          │
│   799 │   │   │   )                                                                              │
│   800                                                                                            │
│                                                                                                  │
│ in pydantic.main.BaseModel.__setattr__:384                                                       │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
ValidationError: 1 validation error for InitInputs
repository
  string does not match regex "^(https://)?github.com/([^/]+)/([^/]+)/?$" (type=value_error.str.regex; pattern=^(https://)?github.com/([^/]+)/([^/]+)/?$)

Expected behavior

I expect nebari init to work properly and create the configuration file according to the options I selected.

OS and architecture in which you are running Nebari

Linux ip-172-31-3-104 6.2.0-1017-aws #17~22.04.1-Ubuntu SMP Fri Nov 17 21:07:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

How to Reproduce the problem?

Go over the nebari init --guided-init and in the GitOps section try the following:

🪴  This next section is optional but recommended. If you wish to adopt a GitOps approach to managing this platform, we will walk you through a set of questions to get that 
setup. With this setup, Nebari will use GitHub Actions workflows (or GitLab equivalent) to automatically handle the future deployments of your infrastructure.


   Would you like to adopt a GitOps approach to managing Nebari? Yes
   Which git provider would you like to use? gitlab.com
   Which user or organization will this repository live under? (https://gitlab.com/<org-name>/) some-org
   And what will the name of this repository be? (https://gitlab.com/some-org/<repo-name>) some-repo

Command output

No response

Versions and dependencies used.

nebari==2024.1.1

Compute environment

None

Integrations

No response

Anything else?

@kalpanachinnappan originally found about this issue
@marcelovilla marcelovilla added type: bug 🐛 Something isn't working needs: triage 🚦 Someone needs to have a look at this issue and triage area: nebari-cli and removed needs: triage 🚦 Someone needs to have a look at this issue and triage labels Feb 21, 2024
@marcelovilla marcelovilla linked a pull request Feb 21, 2024 that will close this issue
Open
10 tasks
@viniciusdc
Copy link
Contributor

Gitlab support has not been tested for some time, so I am not sure if the CI integration would work as well. Would you mind testing that as well, if possible?

@marcelovilla
Copy link
Member Author

@viniciusdc Yes, I also think there are a couple of stuff we're doing for github that we're not doing for gitlab (e.g., setting up the repo). I think that is beyond the scope of this issue but I'll open another one to work on in future releases.

@marcelovilla
Copy link
Member Author

marcelovilla commented Feb 21, 2024 •
edited

Turns out we'll need to account for gitlab groups and subgroups, having repos with the following URL structure:

https://gitlab.com/group/subgroup/repo

@viniciusdc
Copy link
Contributor

@marcelovilla @kcpevey I was going to suggest that we only fix the CI part of this, as it should depend on the repo when pushing/pulling any changes. But, I think the overall work of getting this running would be enough to actually just implement the whole thing for gitlab itself (with auto provision and CI support)

What are your thoughts on this?

@marcelovilla
Copy link
Member Author

I was going to suggest that we only fix the CI part of this

@viniciusdc what do you mean by this? Do you mean Nebari's CI or do you mean rendering the workflow files for the GitOps approach? If it's the latter, those are already being rendered (I haven't tested whether they work, though).

@kcpevey and I outlined two approaches to solve this:

  • Quick approach: get rid of the Which user or organization will this repository live under? and And what will the name of this repository be? questions in the guided init for GitLab as the repo URL does not end up being used at all.
  • More effort approach: make sure to modify the relevant regular expression in pydantic to match GitLab URLs (taking into account that they have groups and subgroups so the URL structure might differ from GitHub repos) and use that information to auto-provision the repo if the user agrees to that. As a matter of fact, I'd only ask the repo URL if the user wants to auto-provision it; otherwise we don't need the information as we don't use it for anything.

I think the second approach is more consistent with what we already have for GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: nebari-cli type: bug 🐛 Something isn't working
Projects
🪴 Nebari Project Management
Status: New 🚦
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Modify regular expression to match both github and gitlab repos. nebari-dev/nebari
2 participants
@marcelovilla @viniciusdc