-
Notifications
You must be signed in to change notification settings - Fork 0
/
rbm.local.conf.example
128 lines (106 loc) · 4.44 KB
/
rbm.local.conf.example
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
128
---
### This file is used to override options from rbm.conf to adapt them
### to your local setup.
###
### Copy this file as rbm.local.conf to enable it, and uncomment the
### options you want to modify.
### The tmp_dir option defines where temporary files are stored. The
### builds are made from this directory, so using a directory on a fast
### disk can improve build time. By default we are using a tmp directory
### under the tor-browser-build directory.
#tmp_dir: /tmp
### The debug option defines whether a debugging shell should be opened
### automatically in the build directory/container in case of build
### failure. If you are doing automated builds, you might want to disable
### this.
#debug: 0
### The build_log option defines in which file the build logs of each
### component are stored. If you set it to '-' the logs are output on
### stdout and stderr.
#build_log: '-'
### By default, the logs from previous builds are kept in the log files.
### If you set build_log_append to 0, then previous logs are cleaned
### when starting a new build.
#build_log_append: 0
### The num_procs option can be used to select the number of
### build processes to run simultaneously. You can also use the
### RBM_NUM_PROCS environment variable. The default is the number of
### processing units available, as returned by `nproc`.
#num_procs: 8
buildconf:
buildconf: 1
### The buildconf/git_signtag_opt option is useful when you tag a release.
### It is used to set the 'git tag' argument to select the keyid for
### signing the tag.
#git_signtag_opt: '-u keyid'
### The buildconf/devmole_auth_token option is used for starting remote builds on
### Mullvad's devmole server using the kick_devmole_build step in the release
### project. Such a token can be acquired from the Mullvad sysadmins.
#devmole_auth_token: abcdefghijklmnopqrstuvwxyz012345
var:
local_conf: 1
### The var/sign_build option defines if you want to sign the
### sha256sums-unsigned-build.txt and
### sha256sums-unsigned-build.incrementals.txt files with gpg.
#sign_build: 1
### The var/sign_build_gpg_opts option can be used to define some gpg
### options to select the key to use to sign the sha256sums-unsigned-build.txt
### and sha256sums-unsigned-build.incrementals.txt files.
#sign_build_gpg_opts: '--local-user XXXXXXXX'
### The var/tpo_user option is used on the release upload_sha256sums step
### and is the user on people.torproject.org that ssh/rsync will try to
### upload the files to
#tpo_user: username
### The clean configuration is used by the cleaning script to find the
### branches and build targets you are using, to compute the list of
### files that should be kept.
###
### If you only do alpha builds for all platforms, you can use the
### following configuration:
#clean:
# HEAD:
# - project: release
# target:
# - alpha
# - torbrowser-all
#
### If you are doing 'release' builds in the maint-7.0 branch and
### 'alpha' builds in the main branch, you can use the following
### configuration:
#clean:
# main:
# - project: release
# target:
# - alpha
# - torbrowser-all
# maint-7.0:
# - project: release
# target:
# - release
# - torbrowser-all
targets:
### testbuild is based on alpha by default. Uncomment this if you want it
### to be based on nightly.
#torbrowser-testbuild:
# - testbuild
# - nightly
testbuild:
var:
testbuild: 1
### Uncomment this if you want to create mar files in your test build.
#build_mar: 1
### Uncomment this if you want to enable the merge_aars step in your test
### build, meaning that GeckoView will be compiled for all architectures.
#android_single_arch: 0
nightly:
### By default 'fetch' is set to 1 for nightly builds, meaning that new
### commits will be fetched automatically during each build. You can
### disable this during development if you want to do rebuilds to test
### a specific change, but don't want rebuilds caused by unrelated
### changes, or if you want to decide at which point new commits are
### fetched. When 'fetch' is set to 'if_needed', new commits will only
### be fetched if the selected commit (or branch, or tag) is not present,
### which means that existing branches won't be updated. In that case
### you can fetch new commits by running 'make fetch'.
#fetch: 'if_needed'
# vim: filetype=yaml sw=2