Instead of passing package specific and global config around separately, parse
them as one config object where package specific can override global should the
same sections and properties exist.
If you maintain custom builders/releasers, they will need to have their
constructors updated.
This may have been a recent change in rpmbuild that caused this as the
_buildroot macro appears to be somewhat new. However it seems using topdir
accomplishes the same thing more thoroughly.
This allows the behaviour to be used in just about any tagger sub-class.
Behaviour will be triggered on the presence of the 'version_template'
section in tito.props.
Renamed config:
version -> version_template (section)
file -> destination_file
Separated the replacement of version and release, as caller may just
want one or the other. (it works fine if only one of the variables is
present in your template file) Release is more of an rpm concept so may
not always be wanted in this context.
Removed the notion of default template files, if you want to use this
you need to specify the configuration for it.
Added a functional test to make sure I keep it working.
Travis[1] runs continuous integration for Open Source projects. With
github, it will run the configured tests and tag pull requests as passing
or failing. This commit adds a Travis configuration.
Since Travis hosts run debian/ubuntu, and execute tests in virtualenv,
getting access to `rpm` and `python-rpm` is impossible, or nontrivial,
at least. For now, ignore the functional tests. To support running the
BuildTargetParser tests, pull that class out into its own module, and
away from release.py, which imports `rpm`.
To configure travis, go to the website, log in with your github account,
then sync your repos under the account tab below your name. Then just
switch the repo to 'on' and it should be all set up.
[1]: http://travis-ci.org
Use regular expression to extract the SHA1 from the `git ls-remote` call
response. The reason is that there might be some messages in the
response going to stderr, that are captured when using run_command,
e.g.:
```
Could not chdir to home directory /home/johndoe: No such file or directory
fe87e2b75ed1850718d99c797cc171b88bfad5ca refs/tags/my-awesome-lib-1.0.1-1
```
I used 30 and more characters for the regular expression because I was
not sure the SHA1 is always shown as 40 characters. However we can be
quite certain that the word of 30 and more [0-9a-f] characters is a
SHA1.
Tito only supported the default build target when releasing,
however, in some cases it was necessisary to change it (building
for zstream for example).
By default, the build target is the same as the branch. With this
change, you can specify a build target on a per branch basis by
adding a 'build_targets' property in the releasers.conf file.
This property takes on the following format:
build_targets = <branch>:<build_target> <branch>:<build_target> ...
An example configuration could be:
[project-x.y.z]
releaser = tito.release.DistGitReleaser
branches = project-x.y
build_targets = project-x.y:project-x.y.z-candidate
Running:
tito release project-x.y.z
would instruct the build system to build with the target
'project-x.y.z-candidate' when building from the project-x.y
branch (i.e rhpkg build --no-wait --target project-x.y.z-candidate).
Will fail unless you have tito installed on your system. In this case
only the bare tito script in bin and seldom modified perl scripts will
be used from the installed version, the code should still run against
the source.
Path hacks currently requiring this, though we still use python-nose
once it's time to actually call the tests. Still probably a solution to
get rid of the test script...
