Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Different versions of TPTP from a build perspective
TPTP Wiki home > Miscellaneous >
The intent of this mini-doc is to record the changes necessary to introduce a new version of the platform/data collection component, at least as it affects the build at Intel. Given that a new version was to be introduced, 4.2.1.1, I chose this as the opportunity to record the things I had to do to handle that new version here so that those that follow can know what to do... and what might need to be automated in the future. I'm updating this mini-doc with the migration from 4.3.0 to 4.4.0 with an eye towards transitioning our end of things in the future. The items listed here are refined so that the 4.2.1.1 => 4.2.2 build migration can go smoothly.
The three Windows systems do their builds in the /home/build/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. This is not possible if there is not already a /home/build/TPTP/<version-number> subdirectory already in place, so creation of those subdirectories is necessary. This also represents a good checkpoint whereby you can ensure that the automatic login via ssh works for the build engineer's login. (Automatic login is done via the ~/.ssh/known_hosts file.)
Build migration time is also a good opportunity to remind us to explore /home/build/TPTP/*/* anyway to see if there are any outdated builds that could stand cleaning up. I usually keep the builds from the last month or so, and remove the rest. Don't worry about losing the build results; they're kept up on the Eclipse archive site.
It's a little more complicated on the Linux boxes. There, the builds are done in the /home/proj/tptp/builder/<arch>/TPTP/<version-number>/TPTP-<version-number>-<timestamp> subdirectory. As for Windows, you'll need to create the /home/proj/tptp/builder/<arch>/TPTP/<version-number> subdirectories, where <arch> is ia32, em64t, and ipf. Most importantly, the build assumes that in this subdirectory will be found a "depends" symlink to the software needed to do the build (the appropriate Java). Make sure to replicate the "depends" symlinks found in the other version-number associated subdirectories.
Updating to a new build number wouldn't be complete without changing the actual build number used by our build scripts, of course. Our builds are driven from sw-opt007 using cron scripts that run every two hours. (Builds take about 1.5 hours, but during heavy network traffic, either locally or between us and IBM-Toronto, it can take more than 2 hours. This can be problematic if one build walks all over another. This seldom happens as the upload usually begins in less than two hours, and the first thing uploaded is the .complete file that signals a build is successful.)
The cron scripts split time between "the latest development build" (usually 10 of the 12 daily attempts, currently moving to 4.4.0) and the latest maintenance point build (usually 2 of the 12 daily attempts, currently 4.2.1.1, soon to change to 4.2.2).
The cron entry launches a build_ia.sh out of the build engineer's ~/releng/org.eclipse.hyades.releng/build/master/bash directory for the main build, and build_ia.4.2.1.1.sh for the maintenance build. (This should be changed to instead checkout the latest releng project for the right build version number at some point in the future.)