Announcing Release 15 of the PostgreSQL Buildfarm client

Changes

• add a new script manage_alerts.pl that lets the user enable or disable alerts for an animal
  This is especially useful in the case of animals that have stopped running for some reason.
• check if a branch is up to date before trying to run it
  This only applies if the branches_to_build setting is a keyword rather than a list of branches. It reduces the number of useless calls to git pull to almost zero.
• require Perl version 5.14 or later
  This should not be a problem, as it's more than 10 years old.
• add --avoid-ts-collisions command line parameter
  This is for specialized uses, and imposes a penalty of a few seconds per run. run_branches.pl already does this, so it's not required for normal operations.
• run TAP tests for src/interfaces subdirectories
• add amcheck and extension upgrade tests to cross version upgrade testing
• adjust to changes in postgres code, file locations, etc.
• assorted minor bug fixes and tweaks

The release can be downloaded from  

https://github.com/PGBuildFarm/client-code/releases/tag/REL_15 or 

https://buildfarm.postgresql.org/downloads

Upgrading is highly recommended.

 

Goodbye Windows XP

This time for sure (h/t Bullwinkle)

Yesterday I finally turned off my Windows XP instance for good. It's been running for quite a long time, almost 12 years, basically as the host for the buildfarm animals currawong, brolga and frogmouth. However, XP itself went out of support on 2014, and in recent years modern Postgres will not build or run on it due to some platform limitations. The latest version of Postgres that could run on it was release 10, which has now reached end of life, so there is no longer a supported version of Postgres that can build on XP, and there is thus no longer a need for these buildfarm animals.

This means we're also probably saying goodbye to Microsoft Visual C 2008, and Msys version 1.

Taming Buildfarm Logs

 The output from running a buildfarm step is the output from running a command such as make check followed by any relevant log files that the step creates. These log files can get quite large, and in some cases there are quite a lot of them. Up to now the buildfarm server has just show all of this in an undifferentiated text blob. That has made finding out what might have gone wrong not impossible but not as easy as it could be, and there have been complaints about it over the years.

A few days ago I implemented a new way of presenting this information. You still see the command output, but instead of showing the log file contents you see a list of the log files. Click on one log file and it will show you the contents of that file. Click on it again and they are hidden again. So if, say, a TAP test fails at script number 12, you can quickly locate the regress_log_012_mytest.log and associated server logs, without having to scroll through thousand of lines that don't interest you.

You can still see the old format if you need to - the page for each stage has a link to the raw log.

I hope this will enhance the usability and usefulness of the buildfarm.

Thanks to Kori Lane for pointing me at the JavaScript gadget that is used to implement this.

Update: All issues now resolved.

Release 14 of the PostgreSQL Buildfarm client

 This is to announce release 14 of the PostgreSQL Buildfarm client.

Significant changes:

• don't run TestUpgrade if TAP tests are present in src/bin/pg_upgrade
• Add proposed new location of pg_upgrade logs in TestUpgrade module
• Use an HMAC over the whole content as the signature.
• Quote PROVE_FLAGS in case there are multiple settings
• tighten failure detection for cross version upgrade
• be more verbose about git mirror failures
• Support symlinks on Windows where possible in SCM module
• Document rm_worktrees setting and make on the default.
• Add new branches_to_build keywords STABLE and OLD

Because of the changes to how pg_upgrade logging works, owners are strongly urged to upgrade to the new release as soon as possible if they are running the TestUpgrade module. 

 

The meaning of the branches_to_build keywords are as follows: STABLE means all the live branches other than master/HEAD, while OLD means those branches older than STABLE that we are now supporting limited builds for (currently REL9_2_STABLE through REL9_6_STABLE). 

 

Downloads are available at https://github.com/PGBuildFarm/client-code/releases and https://buildfarm.postgresql.org/downloads