aboutsummaryrefslogtreecommitdiff
path: root/HACKING
blob: 5baf445af168d3e3c421cea1bd98f5084782433f (plain)
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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
Linaro publishing platform development
======================================

Dependencies
------------

 * python (>=2.7, untested with python3)
 * python-beautifulsoup
 * python-html2text,
 * python-mock
 * python-subunit
 * testrepository (>=0.0.6)
 * python-ldap (3.3.1)
 * django-auth-ldap (1.6.1)
 * python-textile

Code structure
--------------

 * license_protected_downloads/

   Django application doing the file serving for Linaro publishing platform

 * templates/, templates_releases/, templates_snapshots/

   Default and overriding templates for several web sites we run this
   code on.

 * sampleroot/

   Sample root, helpful for development testing.
   Contains all possible combinations of options that are supported.

 * scripts/

   Contains a script for moving files from one location to the public
   location (publish_to_snapshots.py) and a deployment-helper script
   (update-deployment.py).

   jenkins-post-www.sh is an obsolete script replaced by
   publish_to_snapshots.

Style
-----

https://wiki.linaro.org/Platform/Infrastructure/CodingStyle

Upload system
-------------

Upload system deals with files in a private location and moves them into
a corresponding subdirectory under the public location (being served through
the web site).

Script that does that lives in

  scripts/publish_to_snapshots.py

The important concept here is that of "build types": they define what target
directory a build will end up in, and what, if any, postprocessing to do on it.

A simple 'openembedded' job type is added with the following change:

  https://code.launchpad.net/~fboudra/linaro-license-protection/openembedded-support-lp1032134/+merge/118060

Web site for downloads
----------------------

This is a django application, so standard django steps apply:

 ./manage.py syncdb
 ./manage.py collectstatic
 ./manage.py runserver

Run tests with

 ./manage.py test

Overriding templates for particular hosts
.........................................

There is already support for providing separate templates for
releases.linaro.org and snapshots.linaro.org.  Simply put them
inside one of

  templates_releases/
  templates_snapshots/

using the same names as in templates/, and they will be given
preference under appropriate subdomains.

staging instances
.................

lp:linaro-license-protection code gets automatically rolled out every
half an hour to

  staging.snapshots.linaro.org
  staging.releases.linaro.org

API
---
An API is provided to allow scripts to easily interact with the service without
having to scrape the web interface. It is designed as a RESTful service and is
demonstrated in scripts/download.py, which:

 * Gets a directory listing using /api/ls
   - <server>/api/ls/<path to file> returns a JSON document containing all the
     data shown by a file listing on the web interface.
 * Downloads each file, using the type key from /api/ls to avoid directories
 * Displays the license that protects the file to the user by fetching it
   using /api/license.
   - <server>/api/license/<path to file> returns a JSON document containing
     the licence information for the file pointed to. Both the license text
     and the digest used to accept the license are returned. Including the
     digest means that the choice of digest used internally can change without
     re-writing clients - to the client this is just a magic string and they
     don't need to care how it is generated.
 * Stores the digest for each license that the user accepts to avoid asking
   them to accept the same license twice.
 * Downloads each file in the directory by providing the appropriate license
   accept header.
   - The existing web service stores which licenses have been accepted in a
     cookie. This is incompatible with a stateless API and is also
     inconvenient to manage in scripts. The license accept check function now
     checks for a header containing accepted license digests, which scripts
     should use.