Gitea: キャディをメインサーバーとして使用する

Let's Encryptを複数のドメインと統合し、HTTPをHTTPSにリダイレクトします。

オプションである限り、サーバー上のすべてにnginxを使用しており、nginxの背後にあるGiteaを使用して、現在の状態を維持したいと考えています。 その上、私はGiteaでこれらすべての必要性を本当に理解していません。

特定のフロントエンド設定をすべて処理するのはgiteaの役割ではないと思います。 たとえば、gitea-infrastructureの場合、traefikを使用します。ユーザーが内部を設定するための選択は、独自の環境にする必要があります。 giteaは、単純なhttpインターフェースのみを提供する必要がありますが、それを単純に保つ必要があります。

http / 2はどうですか？ （https経由での安全な接続が必要になります）

giteaをキャディプラグインにするだけです：trollface：

+1

@sapkこれはオプションの選択肢だと思います。 それをドキュメントに追加し、サポートします。
特にGiteaPagesは私にとって非常に重要であり、Githubにとって基本的なメリットです。
これらは、数百の静的サイトジェネレーターの1つであるJekkylのみをサポートします。
オープンソースとは、簡単にアクセスできることです。それ以外の場合は、偽善です。
キャディは非常に簡単な方法で、すべての人にhttpsを提供します。 これは、誰にとっても安全なインターネット接続と簡単なWebページを意味します。 これは素晴らしいアイデアだと思います。

キャディとgiteaを並べて使用して、それほど難しくなく、必要なものがすべてここにあるgithubページのように機能する方法を説明できます。 caddyのgitプラグインを使用して変更をプルし、必要に応じてコマンド（hugo、jekyll、またはotherq）を実行するだけです。

GithubページはJekkylでのみ機能します。 Gitlabページはより多くのサポートを提供します。 とにかく私はIPFSに賛成です：

これは分散型ピアツーピアネットワークであり、静的サイトのホスティングを提供します。

https://ipfs.io/
https://ipfs.io/ipfs/QmdPtC3T7Kcu9iJg6hYzLBWR5XCDcYMY7HV685E3kH3EcS/2015/09/15/hosting-a-website-on-ipfs/

Webサーバーと構成にnginx / httpを使用することに同意します

私はこの議論に非常に興味があります...キャディのせいではありません...しかし、この議論が意味することについてです。

Giteaはそれをすべてやろうとしているのでしょうか...それともGiteaは1つのことをして、コア以外のものの統合オプションに依存しているのでしょうか...

Giteaのような製品はコアに焦点を当てるべきだと私には思えます：gitリポジトリ管理、問題、ウィキ、そして他のもののための適切なドキュメントと統合オプションに依存しています。 それはとにかく私の希望です。

オープンソースは選択についてです。 すべてをGiteaに詰め込み、その過程で大きなモノリシックアプリケーションを作成するのは恐ろしいことです。

Giteaの前でキャディとして閉じることは現在機能しています。