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.
You can still reference as tito.builder.Class, but the actual class can be in a
separate module if desired. See __init__.py for the imports that make this
happen.
New builder will not require a tag to function, so we need to remove
assumptions in the CLI about looking it up beforehand and let the
builder itself handle this.
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.
so if it does not exist, create it. This is in-memory operation
and does not affect real file.
Also make disttag optional. If not defined use empty string.
addressing:
Building release in Copr...
Traceback (most recent call last):
File "/usr/bin/tito", line 23, in <module>
CLI().main(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/tito/cli.py", line 94, in main
return module.main(argv)
File "/usr/lib/python2.7/site-packages/tito/cli.py", line 639, in main
scratch=self.options.scratch)
File "/usr/lib/python2.7/site-packages/tito/release.py", line 998, in release
self._koji_release()
File "/usr/lib/python2.7/site-packages/tito/copr.py", line 45, in _koji_release
KojiReleaser._koji_release(self)
File "/usr/lib/python2.7/site-packages/tito/release.py", line 1029, in _koji_release
disttag = self.builder.config.get(koji_tag, "disttag")
File "/usr/lib64/python2.7/ConfigParser.py", line 607, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'copr'
based on KojiReleaser, with few minor changes in KojiReleaser to prevent
duplication of code.
To learn more about Copr see:
https://fedorahosted.org/copr/
sys.stderr.write does not add automatically \n as print does.
Addressing:
Warning: remote.origin do not exist. Assuming --offline, for remote tag checking.Building package [osc-0.132.4-4]
And I checked all sys.stderr.write() occurence in code as well.
Addresses https://github.com/dgoodwin/tito/issues/88
Before this commit: tito fails to build single project when using
git version 1.7.1 (RHEL 6), and `./runtests.py` fails with...
ERROR: test_latest_rpm (functional.singleproject_tests.SingleProjectTests)
ERROR: test_latest_srpm (functional.singleproject_tests.SingleProjectTests)
ERROR: test_latest_tgz (functional.singleproject_tests.SingleProjectTests)
ERROR: test_tag_rpm (functional.singleproject_tests.SingleProjectTests)
ERROR: test_tag_srpm (functional.singleproject_tests.SingleProjectTests)
ERROR: test_tag_tgz (functional.singleproject_tests.SingleProjectTests)
After this commit: tito can build single and multi projects when using
git version 1.7.1 (RHEL 6), and all tests pass.
More info: Git changed the way it interprets tree IDs
between v1.7.3.5 and v1.7.4-rc0.
On git version 1.7.3.5:
$ id="d1fafbe48d24cbb90919b4e886f71c1dc4576c64:./"
$ git archive --format=tar --prefix=tito-0.4.13/ $id | wc -l
fatal: Not a valid object name
0
On git version 1.7.4.rc0:
$ id="d1fafbe48d24cbb90919b4e886f71c1dc4576c64:./"
$ git archive --format=tar --prefix=tito-0.4.13/ $id | wc -l
7837
The `debug` method now takes an optional 2nd argument, which
is a command to run via `run_command` method.
The `run_command` method now takes an optional 2nd argument, which
is used to always print output of command.
If --debug is passed on the CLI, run `git archive` separately
to make problems visible.
Due to error in GemBuilder.tgz method generating the list of sources
there was problem with adding the sources into lookaside (the list of
sources contained all the files in the directory, even directories).
Thanks to 9feb9cf48d the tgz method in
NoTgzBuilder is generic enough to be able to extract the source files
even for GemBuilder.
