2024-01-04 13:06:28 +01:00
|
|
|
ABOUT
|
|
|
|
=====
|
|
|
|
|
2009-07-25 13:29:53 -03:00
|
|
|
Tito is a tool for managing RPM based projects using git for their source code
|
|
|
|
repository.
|
|
|
|
|
|
|
|
Tito offers the following features:
|
|
|
|
|
|
|
|
- Tag new releases with incremented RPM version or release.
|
|
|
|
- Auto-generate spec file changelog based on git history since last tag.
|
2024-01-04 13:06:28 +01:00
|
|
|
- Create reliable tar.gz files with consistent checksums from any tag.
|
2009-07-25 13:29:53 -03:00
|
|
|
- Build source and binary rpms off any tag.
|
|
|
|
- Build source and binary "test" rpms off most recently committed code.
|
2024-01-04 13:06:28 +01:00
|
|
|
- Build multiple source rpms with appropriate disttags for submission to the
|
2009-07-25 13:29:53 -03:00
|
|
|
Koji build system
|
2011-10-16 13:31:57 -03:00
|
|
|
- Build rpms via the "mock" tool.
|
2009-07-25 13:29:53 -03:00
|
|
|
- On a per-branch basis in git:
|
|
|
|
- Maintain concurrent version streams.
|
|
|
|
- Vary the way packages are built/tagged.
|
|
|
|
- Report on any diffs or commits messages missing since last tag.
|
2011-10-16 13:31:57 -03:00
|
|
|
- Define release targets to publish your packages to yum repositories, or
|
|
|
|
the Fedora build system.
|
|
|
|
- Define custom builder/releaser implementations for your own project needs.
|
2009-07-25 13:29:53 -03:00
|
|
|
- Build packages off an "upstream" git repository, where modifications in the
|
|
|
|
"downstream" git repository will be applied as a patch in the source rpm.
|
|
|
|
- Manage all of the above for a git repository with many disjoint packages
|
2011-10-16 13:31:57 -03:00
|
|
|
within it.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
STATUS
|
|
|
|
======
|
|
|
|
|
|
|
|
Copr build: [](https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/tito/package/tito/)
|
|
|
|
|
|
|
|
RELATED PROJECTS
|
|
|
|
================
|
|
|
|
|
|
|
|
* `mockchain` from the [mock project](https://github.com/rpm-software-management/mock/wiki)
|
2015-03-26 14:20:09 +08:00
|
|
|
* `mock`'s built-in SCM support in `mock-scm`
|
2024-01-04 13:06:28 +01:00
|
|
|
* Fedora's [Koji](https://koji.fedoraproject.org/koji/) build engine and [fedpkg](https://fedorahosted.org/fedpkg/) tools
|
2015-03-26 14:20:09 +08:00
|
|
|
* The [OpenSUSE Build Service](https://build.opensuse.org/).
|
2024-01-04 13:06:28 +01:00
|
|
|
* See also [Fedora wiki page for layered build tools](https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers)
|
|
|
|
|
|
|
|
INSTALL
|
|
|
|
=======
|
|
|
|
|
|
|
|
From Fedora:
|
|
|
|
|
|
|
|
dnf install tito
|
|
|
|
|
|
|
|
From CentOS / RHEL:
|
|
|
|
|
|
|
|
# Enable EPEL https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
|
|
|
|
yum install tito
|
|
|
|
|
|
|
|
From [PyPI](https://pypi.org/project/tito/):
|
|
|
|
|
|
|
|
pip install tito
|
|
|
|
|
|
|
|
[Pre-release versions for Fedora](https://copr.fedorainfracloud.org/coprs/g/rpm-software-management/tito/) (built from git `master` branch):
|
|
|
|
|
|
|
|
dnf copr enable @rpm-software-management/tito
|
|
|
|
dnf install tito
|
|
|
|
|
|
|
|
From git's `master` branch:
|
|
|
|
|
|
|
|
- First install Tito's dependencies for your architecture, i.e. `x86_64`:
|
2015-03-26 14:20:09 +08:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
sudo dnf install --setopt=install_weak_deps=False \
|
|
|
|
$(dnf repoquery --arch x86_64,noarch --requires tito --resolve -q)
|
2013-01-25 11:55:49 +00:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
_NOTE: This will install Tito's dependencies from Tito's latest release for
|
|
|
|
your system. If the `master` branch requires a new dependency, it will need to
|
|
|
|
be installed manually._
|
|
|
|
|
|
|
|
- Then install Tito via so-called [User install](
|
|
|
|
https://pip.pypa.io/en/stable/user_guide/#user-installs) (i.e. isolated to the
|
|
|
|
current user):
|
|
|
|
|
|
|
|
pip install --user https://github.com/rpm-software-management/tito/archive/master.tar.gz
|
2013-01-25 11:55:49 +00:00
|
|
|
|
|
|
|
To make an rpm of tito to install elsewhere
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
sudo yum install python-devel asciidoc
|
|
|
|
tito build --rpm
|
|
|
|
# see what's in the package
|
|
|
|
rpm -ql -p /tmp/tito/noarch/tito-*.noarch.rpm
|
|
|
|
|
|
|
|
|
|
|
|
GETTING STARTED
|
|
|
|
===============
|
|
|
|
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
From your git repository:
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
tito init
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
This will create a top-level metadata directory called ".tito/" and commit it
|
2009-07-25 13:29:53 -03:00
|
|
|
to git. This directory will store tito's configuration and package metadata on
|
2024-01-04 13:06:28 +01:00
|
|
|
a per branch basis. It will be filtered out when creating .tar.gz files.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
TAGGING PACKAGES
|
|
|
|
================
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
Before doing most everything you'll need to tag your package(s).
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
Before doing this you'll need to ensure that your package spec files are at the top of the relative source tree for that package.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
For the most common case, a single project git repository has the spec file and
|
|
|
|
root of the project at the top level of the git repository:
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2011-09-13 10:26:16 -03:00
|
|
|
docs/
|
2009-07-25 13:29:53 -03:00
|
|
|
mypackage.spec
|
2011-09-13 10:26:16 -03:00
|
|
|
README
|
2024-01-04 13:06:28 +01:00
|
|
|
.tito/
|
2009-07-25 13:29:53 -03:00
|
|
|
src/
|
2011-09-13 10:26:16 -03:00
|
|
|
test/
|
2024-01-04 13:06:28 +01:00
|
|
|
|
|
|
|
For a multi-project git repository, packages can be defined in various
|
|
|
|
sub-directories, provided they do not nest (i.e. walking up the tree, two spec
|
|
|
|
files will never be encountered):
|
|
|
|
|
|
|
|
.tito/
|
|
|
|
package1/
|
|
|
|
docs/
|
|
|
|
mypackage.spec
|
|
|
|
README
|
|
|
|
src/
|
|
|
|
test/
|
|
|
|
subdir/
|
|
|
|
package2/
|
|
|
|
anotherpkg.spec
|
|
|
|
docs/
|
|
|
|
README
|
|
|
|
src/
|
|
|
|
test/
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
The packages can be organized in any hierarchy you like and even be moved
|
2011-09-13 10:26:16 -03:00
|
|
|
around and re-tagged, we only need to have the spec file in the top level
|
|
|
|
directory for that package.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2011-10-17 12:18:23 -03:00
|
|
|
Tagging packages is normally done with:
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
tito tag
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2011-10-17 12:18:23 -03:00
|
|
|
This will:
|
|
|
|
|
|
|
|
- bump the version or release in the spec file (use --keep-version to use whatever is defined in the spec file)
|
|
|
|
- auto-generate a changelog from first line of each commit since last tag (use --no-auto-changelog if you do not want this)
|
|
|
|
- open an editor allowing you a chance to edit that changelog
|
|
|
|
- insert the changelog into your spec
|
|
|
|
- commit these changes, and generate a git tag
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
By default if you omit --keep-version, tito will tag by bumping the rpm
|
|
|
|
version. (i.e. we bump the Z in X.Y.Z. If you'd prefer to bump the package
|
|
|
|
release instead (normally should just be used for changes to the spec file or
|
2014-03-07 14:29:10 -04:00
|
|
|
patches applied within it), you can change the 'tagger' class in
|
2015-04-26 14:10:11 +02:00
|
|
|
.tito/tito.props to ReleaseTagger. This will affect all packages in this git
|
2009-07-25 13:29:53 -03:00
|
|
|
branch, if you'd prefer to do this on a per-package basis you can do so in a
|
|
|
|
package specific tito.props. (see section below)
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
Once a package is tagged you will need to push both the auto-commit and the tag
|
|
|
|
to your remote git repository before tito will let you build it. (better
|
|
|
|
support for standalone git repositories is coming, for now --offline will help)
|
2009-07-26 22:09:17 +08:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
See "man tito" for more options.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
BUILDING PACKAGES
|
|
|
|
=================
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
To build the most recent .tar.gz for a package, cd into that packages directory
|
|
|
|
and run:
|
|
|
|
|
|
|
|
tito build --tgz
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
Note that this tarball will have a consistent checksum every time.
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
Likewise the --srpm and --rpm options allow you to build both binary and source
|
|
|
|
rpms.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
Add in the --tag=TAG option to build any of the above for any past tag.
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
If you're working on something locally and would like to check that your
|
2024-01-04 13:06:28 +01:00
|
|
|
package is still building ok without pushing your changes to the remote
|
|
|
|
repository, add the --test option. This will build a test rpm from your most
|
|
|
|
recently committed work. (NOTE: does *not* include uncommitted changes)
|
2009-07-25 13:29:53 -03:00
|
|
|
|
|
|
|
TODO: Document the use of --release, which is complicated and untested against
|
|
|
|
Fedora's Koji.
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
See "man tito" for more options.
|
|
|
|
|
|
|
|
|
|
|
|
RELEASING PACKAGES
|
|
|
|
==================
|
2009-08-02 14:51:14 -03:00
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
Tito supports a mechanism where you can define multiple release targets.
|
2009-08-02 14:51:14 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
In .tito/releasers.conf, create a section like:
|
2009-08-02 14:51:14 -03:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
[yum-f15-x86_64]
|
|
|
|
releaser = tito.release.YumRepoReleaser
|
|
|
|
builder = tito.builder.MockBuilder
|
|
|
|
builder.mock = fedora-15-x86_64
|
|
|
|
rsync = fedorapeople.org:/srv/repos/dgoodwin/tito/fedora-15/x86_64/
|
2011-02-03 09:40:56 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
You can define as many release targets as you like with various configurations.
|
|
|
|
To publish the most recently tagged build in your current branch you would run:
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
tito release yum-f15-x86_64
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
You can specify multiple targets on the CLI.
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
See "man 8 releasers.conf" for more information on defining release targets.
|
|
|
|
|
|
|
|
See "man tito" for more information on CLI arguments to "tito release".
|
2011-01-07 16:44:43 -04:00
|
|
|
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
|
|
|
|
CUSTOM BUILDERS / TAGGERS / RELEASERS
|
|
|
|
=====================================
|
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
If the existing implementations Tito provides are not sufficient for
|
2024-01-04 13:06:28 +01:00
|
|
|
your needs, it is possible to define a lib_dir in tito.props buildconfig
|
2011-10-16 13:31:57 -03:00
|
|
|
section. This is a directory that tito will add to the python path during
|
|
|
|
execution, allowing you a place to define your own custom implementations of
|
|
|
|
builders, taggers, and releasers.
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
The process of actually writing a custom Builder/Tagger/Releaser is an exercise
|
|
|
|
left to the reader, but essentially you will want to work off the code in the
|
|
|
|
tito.builder module. Inherit from the base Builder, and override the methods
|
|
|
|
you need to.
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
Please note that if you store your custom implementations inside your source
|
|
|
|
tree, they will need to be kept in sync in all branches you are using for
|
2024-01-04 13:06:28 +01:00
|
|
|
consistent behavior. Also, there are no guarantees that tito will not change in
|
|
|
|
future releases, meaning that your custom implementations may occasionally need
|
|
|
|
to be updated.
|
|
|
|
|
2024-01-04 18:50:49 +01:00
|
|
|
BODHI UPDATES
|
|
|
|
=============
|
|
|
|
|
|
|
|
If you want to automate [Bodhi updates](https://bodhi.fedoraproject.org/), you
|
|
|
|
can utilize [Packit](https://packit.dev/). Create `packit.yaml` in your dist-git
|
|
|
|
repository with this content:
|
|
|
|
|
|
|
|
jobs:
|
|
|
|
- job: bodhi_update
|
|
|
|
trigger: commit
|
|
|
|
dist_git_branches:
|
|
|
|
- fedora-all
|
|
|
|
- epel-7
|
|
|
|
- epel-8
|
|
|
|
- epel-9
|
|
|
|
|
|
|
|
Obviously, you can alter the list of branches to follow.
|
|
|
|
|
|
|
|
For more information, see the documentation of
|
|
|
|
[bodhi_update job](https://packit.dev/docs/configuration/downstream/bodhi_update).
|
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
|
|
|
|
TROUBLESHOOTING
|
|
|
|
===============
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
If you create a tag accidentally or that you wish to re-do, make sure you have
|
|
|
|
not git pushed the tag yet, the auto-commit is the most recent in your git
|
|
|
|
history, and run:
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
git tag -d YOURNEWTAG
|
|
|
|
git reset --hard HEAD^1
|
2011-02-14 09:11:10 -04:00
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
If your project is standalone (no remote reference you communicate with as
|
2024-01-04 13:06:28 +01:00
|
|
|
authoritative) you may wish to set offline = "true" in .tito/tito.props under
|
|
|
|
the buildconfig section, so you do not need to specify --offline with each
|
|
|
|
invocation.
|
|
|
|
|
|
|
|
|
|
|
|
CONFIGURATION
|
|
|
|
=============
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2011-10-16 13:31:57 -03:00
|
|
|
See:
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
man 5 tito.props
|
|
|
|
|
|
|
|
man 5 releasers.conf
|
|
|
|
|
|
|
|
man 5 titorc
|
|
|
|
|
|
|
|
|
|
|
|
COMMUNITY
|
|
|
|
=========
|
|
|
|
|
|
|
|
If you need an advice or want to chat with Tito developers, join us
|
|
|
|
on `#tito` channel at [irc.freenode.net](https://webchat.freenode.net/).
|
|
|
|
|
|
|
|
|
|
|
|
Projects managed with Tito
|
|
|
|
==========================
|
|
|
|
|
|
|
|
Here follows a list of projects managed with Tito. It is not trying to be a complete list
|
|
|
|
of every project using tito but rather a few examples that potential users can check out.
|
|
|
|
|
|
|
|
- [Mock](https://github.com/rpm-software-management/mock)
|
|
|
|
- [Copr](https://pagure.io/copr/copr)
|
|
|
|
- [Tito](https://github.com/dgoodwin/tito)
|
|
|
|
- [Dnf](https://github.com/rpm-software-management/dnf)
|
|
|
|
- [Candlepin](https://github.com/candlepin/candlepin)
|
|
|
|
- [dnf-plugins-core](https://github.com/rpm-software-management/dnf-plugins-core)
|
|
|
|
- [candlepin/subscription-manager](https://github.com/candlepin/subscription-manager)
|
|
|
|
- [rho](https://github.com/candlepin/rho)
|
|
|
|
- [sm-photo-tool](https://github.com/jmrodri/sm-photo-tool)
|
|
|
|
- [vim-fugitive-pagure](https://github.com/FrostyX/vim-fugitive-pagure)
|
|
|
|
|
|
|
|
|
|
|
|
If your project uses Tito, feel free to add it here.
|
|
|
|
|
|
|
|
|
|
|
|
EXTERNAL DOCS
|
|
|
|
=============
|
|
|
|
|
|
|
|
[How to create new release of RPM package in 5 seconds](
|
|
|
|
http://miroslav.suchy.cz/blog/archives/2013/12/17/how_to_create_new_release_of_rpm_package_in_5_seconds)
|
|
|
|
|
|
|
|
[How to build in Copr](
|
|
|
|
http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr)
|
2011-01-07 16:44:43 -04:00
|
|
|
|
2024-01-04 13:06:28 +01:00
|
|
|
[Building RHEL packages with Tito](http://frostyx.cz/posts/building-rhel-packages-with-tito)
|