April 19, 2017
I have released version 4.19 of the PostgreSQL Buildfarm client. It can be downloaded from http://buildfarm.postgresql.org/downloads/releases/build-farm-4_19.tgz
Apart from some minor bug fixes, the following changes are made:
- Include the script’s path in @INC. That means you can usually run the script from anywhere rather than just its own directory.
- Set TZ after “make check” is run. This makes for slightly faster initdb runs in later stages.
- make TAP tests run with –timer
- change default log_line_prefix in config file to use %p instead of %c. That makes it easier to tie log messages to other messages that mention a pid
- Add a module to log running commands to a file as it runs and replace critical uses of “ with the new procedure. That means we have better traces if the buildfarm process crashes.
- Improvements to TAP tests logging and coverage. Each test set (i.e each /t directory) is now logged separately. Coverage is extended to the remaining test sets in src/test except SSL tests.
- Add a module for testing ICU
- change target URL in config file sample to use canonical name matching SSL certificate
- default build_root to a directory in the same place that the script is found, and create it if it doesn’t exist.
- add a command-line flag to allow setting config settings
- from-source path can now be relative
- from-source doesn’t need to specify a branch, if not clear it defaults to HEAD
- from-source can now do vpath builds
These changes mean that the client is more useful for testing development code, and also that testing config settings is much simpler. An initial test run on a fresh installation is now as simple as:
cp buildfarm.conf.sample build-farm.conf ./run_build.pl --test --verbose
To test development code, the from-source option is now much more flexible and friendly. For example, one might do something like:
./run_build.pl --from-source=/path/to/postgresql \ --config-set use_vpath=1 \ --config-set config_opts+=--enable-tap-tests \ --config-set locales+=en_US.utf8
If you run something like this against your development code, and it succeeds, you can be reasonably confident that if committed it won’t send the buildfarm all red.