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

Proposal: Merge Git & SDK repos into main repo #5954

Closed
techknowlogick opened this issue Feb 4, 2019 · 10 comments
Closed

Proposal: Merge Git & SDK repos into main repo #5954

techknowlogick opened this issue Feb 4, 2019 · 10 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first. type/refactoring Existing code has been cleaned up. There should be no new functionality.
Milestone

Comments

@techknowlogick
Copy link
Member

techknowlogick commented Feb 4, 2019

merge git & sdk into this repo. We can still keep same import path (code.gitea.io/git & code.gitea.io/sdk)

I recommend we use folders: modules/git & modules/sdk

Having the two extra repos creates a barrier for new contributions and multiple redundant PRs. Easier if all other two repos were in this one.

Thoughts?

@techknowlogick techknowlogick added type/proposal The new feature has not been accepted yet but needs to be discussed first. type/refactoring Existing code has been cleaned up. There should be no new functionality. labels Feb 4, 2019
@zeripath
Copy link
Contributor

zeripath commented Feb 4, 2019

I think in general this would be a good idea however, we will need to ensure that we somehow keep the external API stable for the SDK. So perhaps we could keep a testing suite outside of the current repo?

I would in particular be very keen to move them in because I think both git and the sdk are not getting updated properly (and I know I'm guilty of this)

@lunny
Copy link
Member

lunny commented Feb 5, 2019

I totally wanted to proposal that before.

@jeanlucmongrain
Copy link
Contributor

jeanlucmongrain commented Mar 10, 2019

I just noticed that there is no test units for the API server (and go-sdk).

I experience few bugs in the go-sdk and I wanted to add tests for the api routers, which will be super easy to do when go-sdk is merged into main repo. Because I just need to implement tests for go-sdk and it will test both server and client.

Will wait until then to do that

@zeripath
Copy link
Contributor

Most of the api is tested in the integrations/ tests.

@jeanlucmongrain
Copy link
Contributor

ah thanks, I was looking into go-sdk for *_test.go files

@sapk
Copy link
Member

sapk commented Mar 20, 2019

This would also be more logic because currently the api response are defined in go-sdk. This would help the swagger part to be more maintained and maybe provide a stable generated client in various coding language directly from the swagger api specs.

@lunny
Copy link
Member

lunny commented May 6, 2019

Is move SDK to gitea main repo is a good idea? Maybe we could move all the structs on gitea main repo and sdk repository could dependent that sub package.

@sapk
Copy link
Member

sapk commented May 6, 2019

@lunny We can even move struct to main and generate the various sdk client from swagger.

@techknowlogick
Copy link
Member Author

techknowlogick commented May 6, 2019

I think it is good for sdk to be in the main repo because we can use sub packages to keep things split up like they are, but still keep PRs manageable. As currently we have to ensure that we merge in sdk PRs before PRs in main repo, it'd be nice if we could just have one PR.

Edit: Just structs are fine too.

@lunny
Copy link
Member

lunny commented May 7, 2019

@techknowlogick yeah, just structs then most time, we don't have to send two PRs to two repo. And SDK could follow some reversion of the structs sub package in go mod to keep compatible.

@lunny lunny added this to the 1.9.0 milestone May 11, 2019
@lunny lunny closed this as completed May 11, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first. type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

No branches or pull requests

5 participants