|
1
|
<title>How The Fossil Download Page Works</title> |
|
2
|
|
|
3
|
<h2>1.0 Overview</h2> |
|
4
|
|
|
5
|
The [/uv/download.html|Download] page for the Fossil self-hosting |
|
6
|
repository is implemented using [./unvers.wiki|unversioned files]. |
|
7
|
The "download.html" screen itself, and the various build products |
|
8
|
are all stored as unversioned content. The download.html page |
|
9
|
uses XMLHttpRequest() to retrieve the [/help/www/juvlist|/juvlist] webpage |
|
10
|
for a list of all unversioned files. Javascript in the |
|
11
|
[/uv/download.js?mimetype=text/plain|download.js] file (which is |
|
12
|
sourced by "download.html") then figures out which unversioned files are |
|
13
|
build products and paints appropriate icons on the displayed |
|
14
|
download page. |
|
15
|
|
|
16
|
Except, the "Source Tarball" download products are not stored as |
|
17
|
unversioned files. They are computed on-demand by the |
|
18
|
[/help/www/tarball|/tarball web page]. |
|
19
|
|
|
20
|
When a new version is generated, the developers use the |
|
21
|
[/help/uv|fossil uv edit] command to make minor changes |
|
22
|
to the "[/uv/download.js?mimetype=text/plain|download.js]" |
|
23
|
file so that it knows about the |
|
24
|
new version number. Then the developers run |
|
25
|
the [/help/uv|fossil uv add] command for each |
|
26
|
build product. Finally, the |
|
27
|
[/help/uv|fossil uv sync] command is run to push all |
|
28
|
the content up to servers. All |
|
29
|
[./selfhost.wiki|three self-hosting repositories] for Fossil |
|
30
|
are updated automatically. |
|
31
|
|
|
32
|
<h2>2.0 Details</h2> |
|
33
|
|
|
34
|
The current text of the "download.html" and "download.js" files can |
|
35
|
be seen at: |
|
36
|
|
|
37
|
* [/uv/download.html?mimetype=text/plain] |
|
38
|
* [/uv/download.js?mimetype=text/plain] |
|
39
|
|
|
40
|
Notice how the hyperlinks above use the "mimetype=text/plain" |
|
41
|
query parameter in order to display the file as plain text |
|
42
|
instead of the usual HTML or Javascript. |
|
43
|
|
|
44
|
The default mimetype for "download.html" is |
|
45
|
text/html. But because the entire page is enclosed within |
|
46
|
|
|
47
|
<verbatim><div class='fossil-doc' data-title='Download Page'>...</div></verbatim> |
|
48
|
|
|
49
|
Fossil knows to add its standard header and footer information to the |
|
50
|
document, making it look just like any other page. See |
|
51
|
"[./embeddeddoc.wiki|embedded documentation]" for further details on |
|
52
|
how this <div class='fossil-doc'> markup works. |
|
53
|
|
|
54
|
With each new release, the "releases" variable in the javascript on |
|
55
|
the [/uv/download.js?mimetype=text/plain|download.js] page is |
|
56
|
edited (using "[/help/uv|fossil uv edit download.js]") to add |
|
57
|
details of the release. |
|
58
|
|
|
59
|
When the JavaScript in the "download.js" file runs, it requests |
|
60
|
a listing of all unversioned content using the /juvlist URL. |
|
61
|
([/juvlist|sample /juvlist output]). The content of the download page is |
|
62
|
constructed by matching unversioned files against regular expressions |
|
63
|
in the "releases" variable. |
|
64
|
|
|
65
|
Build products need to be constructed on different machines. The precompiled |
|
66
|
binary for Linux is compiled on Linux, the precompiled binary for Windows |
|
67
|
is compiled on Windows11, and so forth. After a new release is tagged, |
|
68
|
the release manager goes around to each of the target platforms, checks |
|
69
|
out the release and compiles it, then runs |
|
70
|
[/help/uv|fossil uv add] for the build product followed by |
|
71
|
[/help/uv|fossil uv sync] to push the new build product to the |
|
72
|
[./selfhost.wiki|various servers]. This process is repeated for |
|
73
|
each build product. |
|
74
|
|
|
75
|
When older builds are retired from the download page, the |
|
76
|
[/uv/download.js?mimetype=text/plain|download.js] page is again |
|
77
|
edited to remove the corresponding entry from the "release" variable |
|
78
|
and the edit is synced using |
|
79
|
[/help/uv|fossil uv sync]. This causes the build products to |
|
80
|
disappear from the download page immediately. But those build products |
|
81
|
are still taking up space in the unversioned content table of the |
|
82
|
server repository. To purge the obsolete build products, one or |
|
83
|
more [/help/uv|fossil uv rm] commands are run, followed by |
|
84
|
another [/help/uv|fossil uv sync]. It is important to purge |
|
85
|
obsolete build products since they take up a lot of space. |
|
86
|
At [/repo-tabsize] you can see that the unversioned table takes up |
|
87
|
a substantial fraction of the repository. |
|
88
|
|
|
89
|
<h2>3.0 Security</h2> |
|
90
|
|
|
91
|
Only users with the [/setup_ulist_notes|"y" permission] are allowed |
|
92
|
to push unversioned content up to the servers. Having the ability |
|
93
|
to push check-ins (the [/setup_ulist_notes|"i" permission]) is not |
|
94
|
sufficient. |
|
95
|
|
|
96
|
On the Fossil project there are (as of 2023-07-31) 71 people who have |
|
97
|
check-in privileges. But only the project lead can push unversioned |
|
98
|
content and thus change the build products on the download page. |
|
99
|
Minimizing the number of people who can change the build products |
|
100
|
helps to ensure that rogue binaries do not slip onto the download page |
|
101
|
unnoticed. |
|
102
|
|