1TITO.PROPS(5)                  Tito User Manual                  TITO.PROPS(5)
2
3
4

NAME

6       tito.props - directives for tito(5) how to build package.
7

SYNOPSIS

9       None
10

DESCRIPTION

12       Project settings can be stored in files:
13
14       GITROOT/.tito/tito.props
15
16       GITROOT/SOME/PACKAGE/tito.props
17
18       The global .tito/tito.props is generally where settings are defined.
19       For some multi-project git repositories, individual packages can
20       override these settings by placing a tito.props in the project
21       directory. (i.e. same location as it’s .spec file)
22

SECTIONS

24       tito.props can contain several sections:
25

BUILDCONFIG

27       This section and a couple of it’s properties are required. You can use
28       following variables:
29
30       builder
31           The fully qualified Builder class implementation to use. You can
32           either specify builders shipped with tito(5) (see BUILDERS section
33           below), or a custom builder located within the directory your
34           lib_dir option points to. This property is required.
35
36       tagger
37           The fully qualified Tagger class implementation to use. You can
38           either specify taggers shipped with tito(5) (see TAGGERS section
39           below), or a custom tagger located within the directory your
40           lib_dir option points to. This property is required.
41
42       lib_dir
43           Optional property defining a directory to be added to the Python
44           path when executing tito. Allows you to store custom
45           implementations of Builder, Tagger, and Releaser.
46
47       changelog_format
48           This option is used to control the formatting of entries when
49           generating changelog entries. The default value is "%s (%ae)". See
50           PRETTY FORMATS in git-log(1) for more information.
51
52       changelog_with_email
53           If set to 0, then entries in changelog (subject of commits) are not
54           followed by email of committer. Default is 1. This option is
55           deprecated and provided for backwards-compatibility only. New
56           configurations should consider changelog_format instead.
57
58       changelog_do_not_remove_cherrypick
59           If set to 0, it will not remove from cherry picked commits the part
60           "(cherry picked from commit ...)"
61
62       tag_suffix
63           An optional specification of a suffix to append to all tags created
64           by tito for this repo. Can be useful for situations where one git
65           repository is inheriting from another, but tags are created in
66           both. The suffix will be an indicator as to which repo the tag
67           originated in. (i.e. tag_suffix = -mysuffix)
68
69       tag_commit_message_format
70           This option is used control the text of git commit message that is
71           used when new tag is generated. You can use "%(name)s",
72           "%(release_type)s" and "%(version)s" placeholders.
73
74       tag_format
75           This option controls the format used in VersionTagger. If not
76           specified other taggers.
77
78       sign_tag
79           This boolean enables GnuPG signed tags using git tag -s.
80

KOJI AND COPR

82       disttag
83           Dist tag variable, which is passed to rpmbuild for packages build
84           in this tag.
85
86       blacklist
87           Space separated list of packages, which should not be built in this
88           tag.
89
90       whitelist
91           If whitelist is present, only packages listed here can be built in
92           this tag. This also override blacklist.
93
94       scl
95           Specify name of Software Collection into which package should be
96           build.
97

VERSION_TEMPLATE

99       Allows the user to write out a template file containing version and/or
100       release and add it to git during the tagging process.
101
102       template_file
103           Path to a file conforming to a Python string.Template, as described
104           at http://docs.python.org/2/library/string.html#template-strings.
105           Path is relative to root of the entire git checkout, as this is
106           likely to be stored in the top level .tito directory. The variables
107           $version and $release are available inside the template.
108
109       destination_file
110           Specifies a file to write, relative to the directory for the
111           package being tagged.
112
113       Example:
114
115           [version_template]
116           destination_file = version.txt
117           template_file = .tito/templates/version.rb
118

REQUIREMENTS

120       tito
121           If tito is older then specified version, it will refuse to
122           continue.
123

TAGCONFIG

125       require_package
126           Comma separated list of packages, which needs to be installed prior
127           tagging. If those packages are not installed, tito will refuse to
128           continue.
129

BUILDERS

131       tito.builder.Builder
132           Basic package builder. It create tar.gz of whole directory and
133           create src.rpm and build rpm using some supported method.
134
135       tito.builder.NoTgzBuilder
136           Builder for packages that do not require the creation of tarball.
137           Usually these package have source files checked directly into git.
138
139       tito.builder.UpstreamBuilder
140           Builder for packages that are based off an upstream git tag.
141           Commits applied in downstream git become patches applied to the
142           upstream tarball. For example - you are building package
143           foo-1.2-3... Tar.gz file is created from commit, which is tagged by
144           foo-1.2-1 and the diff between release 1 and 3 is put in spec file
145           as Patch0.
146
147       tito.builder.GemBuilder
148           Builder for packages that list a .gem as Source0, the .gemspec
149           shares a directory hierarchy with the .spec file and the upstream
150           does not want to check .gem files into their git repository.
151
152       tito.distributionbuilder.DistributionBuilder
153           Behave similar as tito.builder.UpstreamBuilder, but patch is
154           created for every release. Therefore package from previous example
155           will end up with tar.gz file created from tag foo-1.2-1 and with
156           Patch0: foo-1.2-1-to-foo-1.2-2.patch Patch1:
157           foo-1.2-1-to-foo-1.2-3.patch
158
159       tito.builder.FetchBuilder
160           See doc/builders.mkd.
161
162           [builder]
163           fetch_strategy = tito.builder.fetch.ArgSourceStrategy
164
165       ArgSourceStrategy here could be replaced with a custom strategy if you
166       were to have one in your lib_dir.
167
168       tito.builder.GitAnnexBuilder
169           See doc/builders.mkd.
170
171       Builder for packages with existing tarballs checked in using git-annex,
172       e.g. referencing an external source (web remote). This builder will
173       "unlock" the source files to get the real contents, include them in the
174       SRPM, then restore the automatic git-annex symlinks on completion.
175

TAGGERS

177       All taggers which inherit from tito.tagger.VersionTagger (all to this
178       date), will update file GITROOT/.tito/packages/name-of-package and put
179       there one line which consist of version-release of package, space
180       delimiter, path to package directory relative to GITROOT.
181
182       tito.tagger.VersionTagger
183           Standard tagger class, used for tagging packages build from source
184           in git. Release will be tagged by incrementing the package version,
185           and the actual "Release" will be always set to 1.
186
187       tito.tagger.ReleaseTagger
188           Keep version and increment release.
189
190       tito.zstreamtagger.zStreamTagger
191           It is used for EUS packages.
192
193       tito.rheltagger.RHELTagger
194           Tagger which is based on ReleaseTagger and uses Red Hat Enterprise
195           Linux changelog format:
196
197           ·   Resolves: #1111 - description
198
199           ·   Related: #1111 - description
200

RELEASER

202       You can create section with the name same as releaser target and there
203       you can specify this option:
204
205       remote_git_name
206           This is useful for FedoraGitReleaser and DistGitReleaser and will
207           allow you to specify name of remote dist-git branch.
208
209           For example let say you have in releaser.conf: [git-sat] releaser =
210           tito.release.DistGitReleaser branches = satellite-6.0-rhel-6
211
212           and then you can add remote_git_name: [git-sat] releaser =
213           tito.release.DistGitReleaser branches = satellite-6.0-rhel-6
214           remote_git_name = ruby193-rubygem-simple-navigation And it will
215           push package into ruby193-rubygem-simple-navigation dist-git
216           despite the fact that it is in /rubygem-simple-navigation
217           directory. And project name (as taken from spec file) is
218           rubygem-simple-navigation.
219
220       tito.susetagger.SUSETagger
221           Tagger which is based on VersionTagger and deal with SUSE / OBS
222           specific separate changes file and format.
223

EXAMPLE

225           [buildconfig]
226           builder = tito.builder.Builder
227           tagger = tito.tagger.VersionTagger
228
229           [koji]
230           autobuild_tags = dist-5E-sw-1.2-candidate dist-f12-sw-1.2-candidate dist-f13-sw-1.2-candidate
231
232           [dist-5E-sw-1.2-candidate]
233           disttag = .el5
234
235           [dist-f12-sw-1.2-candidate]
236           disttag = .fc12
237           blacklist=jabberd-selinux
238
239           [dist-f13-sw-1.2-candidate]
240           disttag = .fc13
241           blacklist=jabberd-selinux
242
243           [requirements]
244           tito=0.3.0
245

SEE ALSO

247       tito(8) titorc(5)
248

AUTHORS

250       Devan Goodwin <dgoodwin@rm-rf.ca>
251
252       James Bowes <jbowes@repl.ca>
253
254       Jan Pazdziora
255
256       Jesus M Rodriguez <jesusr@redhat.com>
257
258       Pall Sigurdsson <palli@opensource.is>
259
260       Miroslav Suchý <msuchy@redhat.com>
261
262       and: Adam Miller, Alex Wood, Aron Parsons, Brenton Leanhardt, Ivan
263       Nečas, John Eckersberg, Kenny MacDermid, Lukáš Zapletal, Luke Meyer,
264       Marian Csontos, Martin Bačovský, Michael Stead, Mike McCune, mscherer,
265       Paul Morgan, Sean P. Kane, Steve Ashcrow Milner
266
267
268
269tito                              03/29/2020                     TITO.PROPS(5)
Impressum