Github provider only lists 100 repositories

[SvenDowideit]

Describe the bug

I seem to have over 200 repositories in my personal account, and registered the GitHub provider with token to get to one of the few private repositories I have there.

I /think/ it's probably just the default page size for the API, so it's not a big thing, compared to the eventual move to using the newer Oauth tokens etc

Expected behavior Ideally, the user would get all infinite repositories, but perhaps the simpler fix is to list the private repositories first, as those are more likely to be the reason for the user to add the provider (instead of just using the git url?

Desktop (please complete the following information):

• Daytona Version: [e.g. v0.23.3]

Additional context

yes, I have too many repositories :)

[SvenDowideit]

ooo, fun rendering issue - when there are more than one page of repositories in the browse list, if the last page has less than the full page number, then the page will have 'ghost' entries that you can't cursor to, left over from the previous page

[Tpuljak]

ooo, fun rendering issue - when there are more than one page of repositories in the browse list, if the last page has less than the full page number, then the page will have 'ghost' entries that you can't cursor to, left over from the previous page

This was fixed with https://github.com/daytonaio/daytona/pull/725 (will be released today).

Regarding the 100 repo limit. Ideally, we should implement proper result pagination, not sure if our TUI even supports that but we should definitely explore that option. Getting all user repos could hit other API limits so properly paginating should be the only viable approach in my opinion.

[SvenDowideit]

This might be lower priority because now that I've configured the GitHub provider with a token that can access my private repos, daytona create https://github.com/SvenDowideit/<private repo> seems to automatically default to that provider, and thus works.

(this wasn't what i expected, so maybe there's some UX/DX improvement that might lead there - for example, i'm not yet sure how to intentionally specify the git-provider when doing a daytona create)

[Tpuljak]

(this wasn't what i expected, so maybe there's some UX/DX improvement that might lead there - for example, i'm not yet sure how to intentionally specify the git-provider when doing a daytona create)

I'm not sure what you mean by this. When running daytona create with configured git providers, you should get a list to choose from.

daytona create https://github.com/SvenDowideit/ seems to automatically default to that provider, and thus works.

Regarding this, this works because we match the source (github.com) to configured providers.

[SvenDowideit]

Ah, so, I've got several different GitHub identities, and organistions (for which I would expect to define different providers - and so would want to explicitly choose a provider (most often by specifying it on the commandline)

So the thing that was unexpected, was that the same command daytona create https://github.com/SvenDowideit/secret does something different if i happen to have changed another configuration.

I'm not saying it's wrong, just that in my overly complicated world, I like to have the ability to control it, and when magic happens, it'd be awesome if daytona tells me :) about that magic specifically.

[Tpuljak]

So the thing that was unexpected, was that the same command daytona create https://github.com/SvenDowideit/secret does something different if i happen to have changed another configuration.

Not sure what you mean by this still 😅 What was the different behavior you're referring to?

Ah, so, I've got several different GitHub identities, and organistions

This is something we could explore. It would require a significant overhaul of how we handle providers, but I get your point. This would require a separate issue and discussion.

[SvenDowideit]

daytona create https://github.com/SvenDowideit/secret has a different outcome in these scenarios:

1. no GitHub git-provider was configured
2. the GitHub git-provider has an API token that has access to that secret repository
3. the GitHub git-provider has an API token that does not have access to that secret repository

and the main reason this is a (minor?) problem, is that it doesn't tell the user about the choices it's made, and that there's no confirmation, or ability to specify which git-provider to use.

i guess a way to think about it, is that implicit easy-path magic in software is a good thing, but only if that magic doesn't come as a surprise, and can't be removed via some explicit way for the user to over-ride the magic.

[Tpuljak]

daytona create https://github.com/SvenDowideit/secret has a different outcome in these scenarios:

1. no GitHub git-provider was configured
2. the GitHub git-provider has an API token that has access to that secret repository
3. the GitHub git-provider has an API token that does not have access to that secret repository

1. the request should fail because the user doesn't have access to the repo
2. the request should pass
3. the request should fail because the user doesn't have access to the repo

Isn't this the expected scenario?

Maybe the confusion is due to how git providers work. When you add a new one with daytona gp new, you are essentially doing a PUT request. Meaning that, if a provider already existed, you are overriding it so there is no choosing a provider when doing daytona create REPO. We automatically choose it based on the source.

[SvenDowideit]

yeah, I guess I used a confusing example too :/

I'm angling towards the idea that the PUT-ness is something that will create an un-necessary confusion for anyone that might replace the provider setting with one that has a different permission scope.

There can (and in my case there are) different contexts where I would have repo workspaces created with incompatible github tokens, and at this point, I would need to remember which token I had PUT into the github provider last, and change it to switch (or create) to a different context.

added to that is the idea that the generic git provider is used for public github repositories, until I setup my first GitHub provider (I presume?)

This thinking kinda started because i wanted to daytona create --git-provider git https://github.com/daytonaio/daytona and compare that to daytona create --git-provider github https://github.com/daytonaio/daytona, and a similar test for some of my private repositories, to confirm that it would fail..

[Tpuljak]

I'm angling towards the idea that the PUT-ness is something that will create an un-necessary confusion for anyone that might replace the provider setting with one that has a different permission scope.

There can (and in my case there are) different contexts where I would have repo workspaces created with incompatible github tokens, and at this point, I would need to remember which token I had PUT into the github provider last, and change it to switch (or create) to a different context.

I agree with this.

Ah, so, I've got several different GitHub identities, and organistions

This is something we could explore. It would require a significant overhaul of how we handle providers, but I get your point. This would require a separate issue and discussion.

As said before, this would require a separate discussion. This issue should be focused on paginating git-provider-related lists (branch, pr, repo...) correctly.

added to that is the idea that the generic git provider is used for public github repositories, until I setup my first GitHub provider (I presume?)

There is no generic provider, if you use https://github.com/daytonaio/daytona without having Github setup, we still use the Github git provider but without authentication. We always need to make an API call to a git provider to get the repo context from which we grab the last commit SHA. You can check out the logic here https://github.com/daytonaio/daytona/blob/main/pkg/server/gitproviders/service.go#L126

This thinking kinda started because i wanted to daytona create --git-provider git https://github.com/daytonaio/daytona and compare that to daytona create --git-provider github https://github.com/daytonaio/daytona, and a similar test for some of my private repositories, to confirm that it would fail..

In light of what I mention above, do you see why this wouldn't make much sense?

[abhishek818]

@SvenDowideit @Tpuljak Have created a new issue related to 'supporting multiple identities for a git provider'. Pls edit/add details in the issue if required.

[lbrecic]

/bounty $100

[algora-pbc[bot]]

💎 $100 bounty • Daytona

Steps to solve:

1. Start working: Comment /attempt #761 with your implementation plan
2. Submit work: Create a pull request including /claim #761 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

If no one is assigned to the issue, feel free to tackle it, without confirmation from us, after registering your attempt. In the event that multiple PRs are made from different people, we will generally accept those with the cleanest code.

Please respect others by working on PRs that you are allowed to submit attempts to.

e.g. If you reached the limit of active attempts, please wait for the ability to do so before submitting a new PR.

If you can not submit an attempt, you will not receive your payout.

Thank you for contributing to daytonaio/daytona!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🔴 @varshith257	Jul 17, 2024, 12:09:23 PM	WIP
🟢 @abhishek818		#776

[varshith257]

/attempt #761 @Tpuljak @lbrecic Can this issue get assigned?

[algora-pbc[bot]]

💡 @abhishek818 submitted a pull request that claims the bounty. You can visit your bounty board to reward.