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.

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

Suggestion for install_gitlab #420

Closed
robertdj opened this issue Aug 9, 2019 · 6 comments
Closed

Suggestion for install_gitlab #420

robertdj opened this issue Aug 9, 2019 · 6 comments
Labels
feature

Comments

@robertdj
Copy link
Contributor

robertdj commented Aug 9, 2019

There are currently some problems with install_gitlab as pointed out in this PR: #308

Furthermore, I am having problems downloading repos with a dot in the name. This is an issue in the GitLab REST API.

But there is another way of accessing repos on GitLab besides the path/to/repo: Every repo has a project id and according to the official docs this can be used instead of the path.

The id can be accessed from the "metadata" of the repo that is already downloaded as part of install_gitlab -- check e.g.
https://gitlab.com/api/v4/projects/jimhester%2Fcovr
https://gitlab.com/api/v4/projects/1486846
The number in the second URL is found in the first.

This metadata can be downloaded in both the problematic situations described above, so if the project id is extracted from the metadata and passed along to remote_download.gitlab_remote I think this would solve both problems.

@jimhester
Copy link
Member

jimhester commented Aug 9, 2019

This sounds like an interesting idea, do you want to try a PR for this?

@jimhester jimhester added the feature label Aug 9, 2019
@robertdj
Copy link
Contributor Author

robertdj commented Aug 9, 2019

Sure, I'll give it a try.

@robertdj
Copy link
Contributor Author

robertdj commented Aug 9, 2019

After having looked more carefully in the code and the related issues it seems difficult/impossible to distinguish between subgroups and subdir from the repo path alone. (As others have concluded previously 😳)
Before going further I would like to hear your thoughts about how much install_gitlab can be changed?

Would it be okay to have a subdir argument like in install_github and drop support for subdir in the repo argument? This change alone would solve the problem with subgroups, but not for repos with dots.

@robertdj
Copy link
Contributor Author

robertdj commented Aug 10, 2019

One more question:

Assuming the subdir / subgroup issue is fixed, there is still the problem of repos with a dot in the name.
In the cases I've tried, DESCRIPTION and the project metadata (in gitlab_commit) can be downloaded with the url encoded repo, but the archive.tar.gz cannot.
This can be fixed by using the project id instead of repo name.

I see two ways:

  • Get the project id from the metadata that is already being downloaded in gitlab_commit. This would be a large change, since it affects install_remote that a lot of other install_*functions also use. install_remote relies on gitlab_commit through remote_sha to return the sha.
  • Download the repo metadata twice -- one in gitlab_commit to get the sha and one to get the project id.

Do you have a preference?

@jimhester
Copy link
Member

jimhester commented Aug 12, 2019

I would not want to change all the other install functions for this, so I think we have to get the metadata twice.

@robertdj
Copy link
Contributor Author

robertdj commented Aug 12, 2019

Sounds good to me. What about subdir as an argument?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature
Projects
None yet
Development

No branches or pull requests

2 participants