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

Gitea hosted Gitea #1029

Open
lunny opened this Issue Feb 23, 2017 · 56 comments

Comments

@lunny
Copy link
Member

lunny commented Feb 23, 2017

For the first big stage, we would like Gitea's development could be based on a Gitea hosted and github will only a mirror. This will maybe completed in v1.x. So that this issue will list all the features needed to be implemented before v1.x. And of course please discuss them and change my post.

@lunny lunny added the kind/proposal label Feb 23, 2017

@lunny lunny added this to the 1.x.x milestone Feb 23, 2017

@Lourens-Rich

This comment has been minimized.

Copy link

Lourens-Rich commented Feb 23, 2017

Very good idea!

@bkcsoft

This comment has been minimized.

Copy link
Member

bkcsoft commented Feb 27, 2017

1.2 in February, 1.3 in April, 1.4 in June, 1.5 in August? should be enough time to implement all that 😄

@zellyn

This comment has been minimized.

Copy link

zellyn commented Mar 10, 2017

If you haven't seen it, fantastic and insightful comment supporting your approach to self-hosting only when ready: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@bkcsoft

This comment has been minimized.

Copy link
Member

bkcsoft commented Apr 7, 2017

@lunny Now that I think about it (thanks @zellyn for that link 😂 ) Why do we need oauth-provider, complete webhook support, api-documentation, and a complete API for self-hosting?

OAuth Consumer is required (it's merged AFAIK) so people can login using github auth.
Drone only uses push hooks, so why would we need the other?

As for API, not sure why self-hosting requires that at all TBH :)

@strk

This comment has been minimized.

Copy link
Member

strk commented Apr 7, 2017

I agree about trimming that list. Earlier self-hosting will very likely help us setting priorities better :)

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Apr 7, 2017

@bkcsoft maybe we can setup a hosted site and have a try.

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Apr 7, 2017

@bkcsoft I updated the issue, do you mean that?

@ekozan

This comment has been minimized.

Copy link

ekozan commented Aug 31, 2017

-> OAuth provider (#27) is not closed

@bkcsoft

This comment has been minimized.

Copy link
Member

bkcsoft commented Aug 31, 2017

@ekozan not closed, but scratched from the list of "things we need"

@bkcsoft

This comment has been minimized.

Copy link
Member

bkcsoft commented Sep 14, 2017

Added "Repository Size Limits" since we don't have unlimited storage on the servers...

My proposal for limits:

  • 0 Orgs
  • 3 Repos
  • 1GB/repo
@lunny

This comment has been minimized.

Copy link
Member

lunny commented Sep 14, 2017

@bkcsoft Did you mean it will be a public service for anyone?

@bkcsoft

This comment has been minimized.

Copy link
Member

bkcsoft commented Sep 14, 2017

Maybe, maybe not, but if it becomes a public service we can't have it unlimited ;)

@stevegt

This comment has been minimized.

Copy link
Contributor

stevegt commented May 5, 2018

I think dogfooding is important enough that repo size limits may not need to be in the critical path for self-hosting gitea. In the first few days after migrating to gitea, I've run across several feature omissions that made me think self-hosting will help focus effort on getting those things done. Gitea is already a fantastic, highly usable, high-performance tool -- it's a real shame you aren't using it yourselves. ;-)

Rather than depend on hard size limits, it might instead be helpful to think about how the self-hosted server is going to be administered, who's going to police bad behavior, and what tools they will want. For instance, contributor forks of the gitea project ought to be supported on gitea's own server. This exposes the risk that a user forks gitea, then pushes warez to their fork. Size limits might help prevent pushing large binaries, but might not help with a list of passwords or credit card numbers. A tool that might help in that case is something that detects alien files by diff line count or rolling hash.

A nice side-effect of having a diff-size tool available is that the code could be available as an option to run during pushes to flag legitimate commits that should have been broken up into smaller pieces anyway. (Related discussion for ways to do this: #3658 (comment).)

I'd bet there are a lot of other subtle things that will need to be addressed for public-facing servers. It might make sense to use a separate "public hosting" master issue or milestone to track these things.

@stevegt

This comment has been minimized.

Copy link
Contributor

stevegt commented May 5, 2018

Speaking of milestones, should this issue be added to 1.5.0?

@jonasfranz

This comment has been minimized.

Copy link
Member

jonasfranz commented May 6, 2018

@stevegt No, since I think that not all of the PRs will get merged / resolved at 1.5.0.

@lunny

This comment has been minimized.

Copy link
Member

lunny commented May 8, 2018

I removed Repository Size Limits (#3658) from the issue since it will not affect Gitea hosted gitea.

@mxmehl

This comment has been minimized.

Copy link

mxmehl commented May 9, 2018

I removed Repository Size Limits (#3658) from the issue since it will not affect Gitea hosted gitea.

Great! I'm positive that the sooner Gitea hosts itself, the faster will the whole project profit from real-life experiences, and gain trust and confidence :)

@justinclift

This comment has been minimized.

Copy link
Contributor

justinclift commented Jun 4, 2018

@lafriks mentions in another thread:

Self-hosted would probably require additional funding/sponsorship to pay for additional virtual machine

And @lunny asks above:

@bkcsoft Did you mean it will be a public service for anyone?

Would it be feasible to combine those thoughts into a "How about setting up an online Gitea service, where people pay for (say) private repos?".

If done ok, that should generate the funds to pay for itself + the public repos.

As a concept, it seems to be fairly well travelled ground. 😄

@drsect0r

This comment has been minimized.

Copy link
Contributor

drsect0r commented Jun 4, 2018

To promptly add to @justinclift idea; the timing might be right with the current news of Microsoft taking over GitHub.

@mxmehl

This comment has been minimized.

Copy link

mxmehl commented Jun 4, 2018

@lafriks mentions in another thread:

Self-hosted would probably require additional funding/sponsorship to pay for additional virtual machine

I'm confident that there will be funding from the community or sponsorship from organisations to make gitea hosting itself possible. Since Gitea is resource-friendly (yes, GitLab, I'm looking at you) this won't be a big deal.

@techknowlogick

This comment has been minimized.

Copy link
Member

techknowlogick commented Jun 4, 2018

@mxmehl so far there have been 5 individuals that have contributed since the opencollective was open last month: https://opencollective.com/gitea

@lafriks

This comment has been minimized.

Copy link
Member

lafriks commented Jun 4, 2018

@justinclift as Gitea is purely community for driven there is no way we could set up paid private repositories as that requires creating company, dealing with taxes, and have full time staff to deal with technical problems

@mxmehl

This comment has been minimized.

Copy link

mxmehl commented Jun 4, 2018

@mxmehl so far there have been 5 individuals that have contributed since the opencollective was open last month: https://opencollective.com/gitea

@techknowlogick Didn't know this page. Now it's 6 ;)

@justinclift

This comment has been minimized.

Copy link
Contributor

justinclift commented Jun 4, 2018

@lafriks Well.... there are Community projects around - for both software and non-software things - which seem to manage themselves ok, including financial matters, things they pay for, staff (where needed), and so on.

That being said, it does require a level of will to make it happen + keep it going. The people in any needed roles also need to be good custodians (trustworthy, reliable, clueful).

If there's no interest, then it won't go anywhere anyway. Ditto if no suitable "custodian" types can be agreed upon.

From the Open Collective link mentioned above, it looks like some initial seeds are in place. It demonstrates there are people around who are considered ok as custodians. 😄

@stevegt

This comment has been minimized.

Copy link
Contributor

stevegt commented Jul 5, 2018

@bkcsoft Fair enough -- just thought I'd mention it in case it triggered any realizations. In our local case, we've been developing the habit of manually adding the backlinks in issue comments as a workaround.

@jlelse

This comment has been minimized.

Copy link

jlelse commented Jul 9, 2018

I recently heard about the effort of https://teahub.io. They want to start a non-profit org. Can't Gitea use that once they are ready with the setup?

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Jul 9, 2018

@jlelse No. Gitea will set up a standalone server (i.e. self.gitea.io) to host gitea and mirror to github, gitlab or teahub and etc.

@jonasfranz

This comment has been minimized.

Copy link
Member

jonasfranz commented Jul 9, 2018

@lunny Do we really require commments on commits since we are currently only using comments on PR at GitHub?

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Jul 11, 2018

@JonasFranzDEV I mean comments on commits of PR, I think it's necessary.

@ryanburnette

This comment has been minimized.

Copy link

ryanburnette commented Aug 25, 2018

I'm commenting here because #4108 is closed. When the Gitea Patreon (or Patreon-like alternative) goes up, I need to know about it. I'll be contributing. I'd like to see this project self-hosted and further developed. Once I move all my repositories I won't be spending money with Github anymore, I'll commit that monthly to the Patreon.

@techknowlogick

This comment has been minimized.

Copy link
Member

techknowlogick commented Aug 25, 2018

@mjmlvp

This comment has been minimized.

Copy link

mjmlvp commented Sep 8, 2018

@lunny looks like 'Approval system' in the topic start can be crossed out. (The issues being respectively closed and merged)?

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Sep 9, 2018

@mjmlvp I think you are right. I removed #996 #2519 since it should not be a block of this issue. We will set up a server to host our developments.

@strk

This comment has been minimized.

Copy link
Member

strk commented Oct 9, 2018

Any news on this ?

@lafriks

This comment has been minimized.

Copy link
Member

lafriks commented Oct 9, 2018

Yes we still need to add approval limitations and then we can migrate to selfhosted code

@skddc

This comment has been minimized.

Copy link

skddc commented Oct 10, 2018

Would be nice to add the open issues for that to the list. At the moment it looks like all linked issues and PRs have been closed and merged.

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Oct 10, 2018

@skddc done.

@milahu

This comment has been minimized.

Copy link

milahu commented Nov 1, 2018

for the record

open gitea servers

trust no one. make regular backups

@ptman

This comment has been minimized.

Copy link
Contributor

ptman commented Nov 29, 2018

@giteauser I fail to see how that is relevant

@ptman

This comment has been minimized.

Copy link
Contributor

ptman commented Nov 29, 2018

@giteauser and this is about self-hosting gitea development, so that gitea development doesn't have to happen on github anymore. I still fail to see how this is relevant.

@ghost

This comment has been minimized.

Copy link

ghost commented Nov 29, 2018

Oh I posted these for the wrong issue, I'm sorry.

@davidak

This comment has been minimized.

Copy link

davidak commented Dec 12, 2018

So, every needed feature should be implemented now. Can we have a new release and migrate away?

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Dec 12, 2018

Right, we will setup a gitea instance to host gitea's development.

@lafriks lafriks modified the milestones: 1.x.x, 1.7.0, 1.8.0 Dec 12, 2018

tarsius added a commit to magit/forge that referenced this issue Dec 18, 2018

Support teahub.io host
Note that this host is in pre-alpha and that it is not clear whether
the operators are trustworthy.

I have only added this to `forge-alist' because I couldn't find any
other more trustworthy *and* persistent public instances but needed
something for testing purposes.  The Gitea maintainers plan to create
their own instance, see go-gitea/gitea#1029.
Once that is available, I will probably remove teahub.io again.

I am also not happy about having to modify `forge--url-regexp' just
for this one host, which is another reason I might stop supporting it
when something better comes along.

Also remove the "gitea.local" host, which I used for testing early on.
Note that local installations of both Gitea and Gogs are available on
localhost:3000 by default.  So adding such a Gitea instance to the
default value of `forge-alist' made it a bit harder for people trying
out Gogs.

tarsius added a commit to magit/forge that referenced this issue Dec 18, 2018

Support teahub.io host
Note that this host is in pre-alpha and that it is not clear whether
the operators are trustworthy.

I have only added this to `forge-alist' because I couldn't find any
other more trustworthy *and* persistent public instances but needed
something for testing purposes.  The Gitea maintainers plan to create
their own instance, see go-gitea/gitea#1029.
Once that is available, I will probably remove teahub.io again.

I am also not happy about having to modify `forge--url-regexp' just
for this one host, which is another reason I might stop supporting it
when something better comes along.

Also remove the "gitea.local" host, which I used for testing early on.
Note that local installations of both Gitea and Gogs are available on
localhost:3000 by default.  So adding such a Gitea instance to the
default value of `forge-alist' made it a bit harder for people trying
out Gogs.
@max-wittig

This comment has been minimized.

Copy link
Contributor

max-wittig commented Jan 9, 2019

I think fixing the backup dump issue and adding proper restore functionality is also an important part to managing infrastructure of a self-hosted gitea

@skddc

This comment has been minimized.

Copy link

skddc commented Jan 10, 2019

If you're deploying Gitea on Kubernetes, I can recommend Ark for backups and restores.

Generally speaking, backup doesn't seem like it should be a blocking topic for self-hosting Gitea development, because everyone usually has different backup strategies/programs, depending on their choice of platform, method of deployment, existing tools, etc.. It should only be a blocking issue for that very instance's production readiness.

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Jan 10, 2019

@max-wittig The gitea self-hosted website will run on some public cloud provider. They will provide RDS service and database backup tool and some disk backup function so that backup dump command is not a dependency issue. The dump command is for a single-node gitea service. Of course we should fix that issues.

@lunny

This comment has been minimized.

Copy link
Member

lunny commented Jan 10, 2019

@skddc It's an interesting tool that we can consider that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment