These tests began failing after a correction to another test. The
other test had been patching the error_out function without unpatching
it and thus polluted the test environment.
Also reset to a known directory at the beginning of the common tests so
that we don't start in a directory that has since been unlinked.
The Maven-generated tar file deviates from the spec in several places.
Fields are padded out with spaces instead of NUL bytes and the user and
group ID are left empty.
This patch alters the tar module to correct these issues and ensures a
consistent unchanging fingerprint for the archive by setting the mtime
on the files to the modified time of the commit.
The Python 2.4 style of getting an exception object is forbidden by the
test_exceptions_3 test. Something has to give, and Tito is not being
built for RHEL 5 anymore.
Python's read(N) function only guarantees that it will read no more
than N bytes but not that it will return N bytes. This patch adds a
function that will ensure exactly N bytes are read.
Tito passes "git archive" a tree ID. The "git archive" man page states:
git archive behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time
is used as the modification time of each file in the archive.
Using the current time means that every time we build the source
tarball, the file fingerprint will change since the metadata in the
tarball changes. We don't want that since build systems track the
fingerprint to see if the actual source has changed.
This process was previously handled in an enigmatic Perl script that
lacked any comments whatsoever. Converting it to well-commented Python
makes the process less mysterious and speedier since Tito doesn't need
to shell out to Perl.
Use RawConfigParser instead of ConfigParser to avoid...
Traceback (most recent call last):
File "/home/sandbox/test/functional/multiproject_tests.py", line 68, in setUp
self.create_project(TEST_PKG_1, os.path.join(self.repo_dir, 'pkg1'))
File "/home/sandbox/test/functional/fixture.py", line 198, in create_project
tito('tag --keep-version --debug --accept-auto-changelog')
File "/home/sandbox/test/functional/fixture.py", line 103, in tito
return CLI().main(argstring.split(' '))
File "/home/sandbox/src/tito/cli.py", line 222, in main
return module.main(argv)
File "/home/sandbox/src/tito/cli.py", line 671, in main
offline=self.options.offline)
File "/home/sandbox/src/tito/tagger/main.py", line 51, in __init__
ConfigObject.__init__(self, config=config)
File "/home/sandbox/src/tito/config_object.py", line 38, in __init__
config.get(section, options))
File "/usr/lib64/python3.3/configparser.py", line 1184, in set
super().set(section, option, value)
File "/usr/lib64/python3.3/configparser.py", line 889, in set
value)
File "/usr/lib64/python3.3/configparser.py", line 399, in before_set
"position %d" % (value, tmp_value.find('%')))
nose.proxy.ValueError: ValueError: invalid interpolation syntax in '%s (%ae)' at position 0
03255001d6 moved commands module to src/tito/compat.py to handle
differences between python2 and python3, but missed a bit that
did not show up in unit or functional tests.
Fix those occurences and add unit test to detect the regression.
python3 does not allow relative imports.
test/unit/__init.py__ and test/functional/__init.py__ already exist,
which means we can use absolute import on all versions of python
without resorting to http://legacy.python.org/dev/peps/pep-0328/
Python 3 does not have the print statement, so convert all
print statements to print functions and add an ugly duckling
unit test to detect regressions.
Add modules compat lib to support both python 2 and 3, and
add unit test to detect regressions.
Tito uses two modules that have changed significantly between
python 2 and 3:
* commands module merged into subprocess module
* ConfigParser module renamed as configparser
Exceptions are now compatible with both python 2.4 and 3.3,
and we have unit tests to detect regressions.
The syntax for capturing exceptions changed in python 3, but
we need to continue supporting python 2.4 syntax since many
people use tito on RHEL 5, which has python 2.4.
http://docs.python.org/dev/howto/pyporting.html#capturing-the-currently-raised-exception
These are the pep8 tests that break python3,
such as mixing tabs and spaces for indentation.
I ignored all the pep8 tests that seemed only stylistic,
such as "visual" indentation.
http://docs.python.org/3.3/reference/lexical_analysis.html
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).
