Open SvenDowideit opened 1 month ago
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
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.
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
)
(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.
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.
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.
daytona create https://github.com/SvenDowideit/secret
has a different outcome in these scenarios:
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.
daytona create https://github.com/SvenDowideit/secret
has a different outcome in these scenarios:
- no GitHub git-provider was configured
- the GitHub git-provider has an API token that has access to that secret repository
- the GitHub git-provider has an API token that does not have access to that secret repository
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.
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..
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?
@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.
/bounty $100
/attempt #761
with your implementation plan/claim #761
in the PR body to claim the bountyIf 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 |
/attempt #761 @Tpuljak @lbrecic Can this issue get assigned?
💡 @abhishek818 submitted a pull request that claims the bounty. You can visit your bounty board to reward.
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):
Additional context
yes, I have too many repositories :)