* Add a script make-dist-tarball.py that runs 'setup.py sdist' and compares
what gets distributed with git and with a set of patterns of extra files
added during distribution, and with git files that we don't want to
distribute.
* Extend MANIFEST.in or add __init__.py files to distribute:
run-unittests.sh
tox.in
conf/client_secrets.json
tests/test_builder
tests/integration
* Don't include all of module_build_service - this is too prone to backup
files and development trash files; instead add just the files we need
that aren't *.py
* Move global-excludes to the end - they modify the existing list of files;
and add *.db - for some reason, .mbs_local_build.db files were
getting disted.
To clean things up and facilitate future changes to test cases, split
the method for creating a builder apart from the fixture so that it can
be used independently.
Verbose output from mock is not useful for someone trying to figure out
why their module build failed, and in fact makes it harder by adding
quite a bit of extraneous noise.
Mock doesn't normally log anything to stdout - so it's confusing to mention
separate logs in the messages. Combine the two output streams together.
(This is what koji does as well.)
The different build threads all are using the same basic build root
contents, so there's no reason to use separate caches - point the
root cache plugin for mock to a single location. (There's locking
inside Mock for updating the root cache.)
The mod time for the mock configuration file is used to determine
whether the root cache is out-of-date or not, so we want to avoid
changing the configuration timestamps when we don't change content
when we're just writing a per-thread mock configuration file again
with no substantive changes.
We do this by only updating the master mock.cfg file when we're
actually adding content, and propagating its mod time to the
per-thread configuration files.
When we want to pass in SCM options particular to a specific module build,
do that on the mock command line rather than by modifying mock.cfg - this
avoids invalidating the root cache.
For local builds, required modules are not necessarily in the local
database, so the method of looking up the build to find the koji tag
doesn't work reliably. However, the caller has the koji_tag - so just
pass it in.
When downloading files from Koji to make a local repository, display
a temporary status of which files are being displayed to the console
appended after any log messages. Updates are done by erasing the status
that was written, adding a log message, then writing the status again.
When running in local mode, add a special handler that filters log
messages to the console to produce attractive output. Implemented
behaviors include:
- INFO level messages are only displayed if done through
MBSLogger.console() rather than MBSLogger.info().
- Timestamps and thread names are omitted unless the local build
is started with the -d option
- Warning/error messages have the level highlighted in red
- Special handling can be added to log messages, initially:
- Long running operations can be displayed to the console as
"Doing foo ... <pause>done"
all_reused_in_prev_batch should only check components in the previous
batch, not components in all batches including future batches. This
was accidentally regressed by some code refactoring in c36bd7ebac.
Since the build log is already within the a build-specific directory, we
don't need to put the build ID (which ends up always being "2") into the
build log filename.
Logging during a build that occurs before the build directory is created
used to be logged to the console, but not retained in the build log
file. This made referring to the build log file confusing. Solve this
by buffering logs in memory until the log file is created and replaying
them.
A little bit of hackery is needed to avoid saving dangling references to
libsolv objects.
