The bootstrap fetches and invokes the main build script, called [http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.releng/builder/scripts/masterBuild.sh masterBuild.sh]. This script is under version control, so you need to push any changes to this script into the master branch for them to take effect.

+

The bootstrap fetches and invokes the main build script, called [http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.releng/builder/scripts/masterBuild.sh masterBuild.sh]. This script is under version control, so you need to push any changes to this script into the master branch for them to take effect. If you scroll to the very bottom of this script you can see the steps it performs:

The results of the build, including any failures from any step, can found found in the build log at:

+

+

/shared/eclipse/e4/orion/logs/current.log

+

+

This is the first place to check when the build fails. It is typically very long so it is often helpful to use <tt>tail</tt> to start near the end. This exact same log gets copied into the download directory so it is available for reference for any build we produce. For example:

For performance reasons, PDE build maintains a cache of fetched prerequisite bundles. This lives at /shared/eclipse/e4/orion/target/transformedRepos on the build machine. The build will pick up the newest version of each required bundle from that location. If you ever need to force the build to go back to an *older* version of a bundle, this cache needs to be cleared. Simply delete the transformedRepos directory prior to the build.

+

+

== Deploying builds to orion.eclipse.org or orionhub.org ==

+

+

Builds are deployed using the script [http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.releng/builder/scripts/deploy.sh deploy.sh]. This script should be copied to your home directory and run from there. Your home directory will contain a symlink to the downloads directory, so you can perform a deploy directly from the downloads area. The script takes a single argument which is the location of the zip containing the download. For our servers we want the Linux 64-bit build. It is useful to log the output of this script so it can be reviewed later. Example:

This script simply copies the build onto the deployment server, and invokes an upgrade script on that server - [http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/tree/releng/org.eclipse.orion.releng/builder/scripts/upgrade.sh upgrade.sh]. The upgrade script shuts down the old server, moves it, unzips and configures the new build, and finally starts it.

+

+

The entire deploy/upgrade process takes about 5 seconds when it runs smoothly. Occasionally there will be a communication error copying the new build onto the target machine. In this case simply re-running the script usually succeeds.

+

+

=== Server configuration ===

+

+

The [[Orion/Server_admin_guide#Server_configuration_file|server configuration file]] on orion.eclipse.org and orionhub.org is found in ~admin/current/orion.conf. This file gets copied into the server by the deployment script. So, any change made to this configuration file will take effect only on the next deployment.

= FAQ =

= FAQ =

−

=== How often do I need to tag? ===

+

−

You don't need to tag every commit. Changes only need to be tagged when a build is scheduled. I-builds are scheduled to run Monday Night/early Tuesday morning, changes should be tagged and map files updated at the end of day Monday. For high-traffic projects that many people are working on, it is good to coordinate who will tag those projects. For low-traffic bundles that rarely get changed, sometimes it is good to tag right away when a change is made so that you don't forget later.

+

[[Category:Orion|Releng Builds]]

[[Category:Orion|Releng Builds]]

Revision as of 12:56, 24 February 2012

The Orion builds follow many of the same practices used by the Eclipse Platform Project. The builds are based on PDE/Build and run automatically on build.eclipse.org via cron job.

There is only one kind of build. Integration builds run daily from tagged repository versions. Map files are used to specify where a project is located in the repository and what version of that project to use in the build. The map files are located in the org.eclipse.orion.releng project. The builder itself performs the tagging so all the latest changes in "master" stream are picked up by every build. No manual tagging by committers is required.

How the build works

Bootstrap

The build is kicked off by a "bootstrap" script that is not under version control. The only purpose of this script is to fetch the real build script and invoke the build. The script is located at:

/opt/buildhomes/e4Build/bootstrap.orion.sh

The build type is passed as an argument. -I means integration build (with tagging). -N is equivalent but does not perform any tagging (in both cases the contents of master are used to perform the build).

You can also pass an -email argument to cause the build notifications to only be sent to an individual. This is useful for test builds:

bootstrap.orion.sh -I -email bob_mackenzie@example.com

The bootstrap script is typically invoked by a cron entry in the e4Build user account. For example here is a cron entry to start a build every Wednesday at 8:55am:

masterBuild.sh

The bootstrap fetches and invokes the main build script, called masterBuild.sh. This script is under version control, so you need to push any changes to this script into the master branch for them to take effect. If you scroll to the very bottom of this script you can see the steps it performs:

build log

The results of the build, including any failures from any step, can found found in the build log at:

/shared/eclipse/e4/orion/logs/current.log

This is the first place to check when the build fails. It is typically very long so it is often helpful to use tail to start near the end. This exact same log gets copied into the download directory so it is available for reference for any build we produce. For example:

Repository cache

For performance reasons, PDE build maintains a cache of fetched prerequisite bundles. This lives at /shared/eclipse/e4/orion/target/transformedRepos on the build machine. The build will pick up the newest version of each required bundle from that location. If you ever need to force the build to go back to an *older* version of a bundle, this cache needs to be cleared. Simply delete the transformedRepos directory prior to the build.

Deploying builds to orion.eclipse.org or orionhub.org

Builds are deployed using the script deploy.sh. This script should be copied to your home directory and run from there. Your home directory will contain a symlink to the downloads directory, so you can perform a deploy directly from the downloads area. The script takes a single argument which is the location of the zip containing the download. For our servers we want the Linux 64-bit build. It is useful to log the output of this script so it can be reviewed later. Example:

This script simply copies the build onto the deployment server, and invokes an upgrade script on that server - upgrade.sh. The upgrade script shuts down the old server, moves it, unzips and configures the new build, and finally starts it.

The entire deploy/upgrade process takes about 5 seconds when it runs smoothly. Occasionally there will be a communication error copying the new build onto the target machine. In this case simply re-running the script usually succeeds.

Server configuration

The server configuration file on orion.eclipse.org and orionhub.org is found in ~admin/current/orion.conf. This file gets copied into the server by the deployment script. So, any change made to this configuration file will take effect only on the next deployment.