1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
.'.'
.'-'.
. ( o O)
\_ ` _, _
-.___'.) ( ,-'
'-.O.'-..-.. octopus git web frontend
./\/\/ | \_.-._
;
._/
A git web frontend that wants to hug your code.
Why?
----
This is a very good first question, and one that I think is important
to answer before getting more into the project. Whenever I brought up
this project during the creation of it, most people would react with
"have you tried...", followed by some git web software, such as
gitlab, gittea, and many many more. But there is a reason why I stuck
with octopus and the design ideas I had for it.
Fundamentally it's about decentralisation. The internet is a pretty
big place (allegedly), but a lot of the services that people use are
very centralised by a single company or even server. If this company
or server goes away, so does valuable knowledge. There are many ways
to create more decentralised systems, and one aspect of this for me,
is code repos.
Git is by it's nature decentralised, meaning that it doesn't require
an "upstream" or canonical server to function. Theoretically you
could use git to exchange code patches with people without the
internet. Yet, a lot of people's perception of git is one that is
dictated by the workflows on github and gitlab: centralised into a
single service. Many git web frontends mirror this workflow, because
after all, it is what people want and love.
However, it has some flaws (which would take too long to elaborate
here), and for octopus I had something else in mind. Instead of
replicating the same mistakes, I took much more inspiration from cgit,
which is used and loved by many today. octopus is a re-imagining of
cgit, trying to improve the UX and maintainability where possible,
adding new features, but mostly staying true to it's core: a simple
git web service, that doesn't lock you into a vendor, or server.
Configuration
-------------
octopus is easy to configure and run, even on systems that don't give
you priviledged system access. The main server binary is configured
primarily with a few environment variables, and an app config.
+ OCTOPUS_CONFIG should contain the path of the main configuration
+ OCTOPUS_SSL_KEY can optionally be set to the path of a certificate key
+ OCTOPUS_SSL_CERT can optionally be set to the path of a certificate
The main configuration file is written in yaml, and outlines things
like the application domain, repo paths, and added modules. Because
octopus is vory modular, you can only depend on certain features.
---
app_path: git.octopus.example
port: 8080
handle_ssl: false
cache_path: /var/cache/octopus
repo_path: /var/lib/octopus/repos
repo_discovery: false # Disables automatic config loading from repo_path
# and instead let's you set a static set of repos
# in the section below
repos:
- octopus:
description: "🐙 It's a water animal"
category: "/"
- libkookie:
description: "My personal nix expressions"
category: "/nix"
|
