Skip to main content

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.

Jump to: navigation, search

COSMOS RE AND BUILD

Revision as of 23:28, 18 November 2007 by Jagmits.ca.ibm.com (Talk | contribs) (Introduction)

This page will hold information and links around Release Engineering and build

Introduction

COSMOS Build (Release Engineering)

Build Overview


COSMOS Deliverables
Following are the deliverables available from the eclipse downloads site:
http://www.eclipse.org/cosmos/downloads/

1. SML validator and SML-IF Editor (Resource Modeling)
This consists of an SML validator that validates SML and SML-IF files, an editor to create and validate SML-IF documents used to exchange information between systems management applications, and tools for importing and exporting SML data to and from a flat file repository. This is a set of Eclipse plug-ins for tooling, packaged as a zip file.


2. Data Collection Framework
This is a set of OSGi bundles and can run in any OSGi container. But this is currently packaged in eclipse plug-in format as a zip file.
Current OSGi Bundles in COSMOS:
http://wiki.eclipse.org/COSMOS_DC_OSGi_Bundles


3. Data Reporting Web Application
This is a web application. It bundles the COSMOS Report Viewer and the COSMOS UI.


Project – Deliverable Mapping

ProjectDeliverable
Data Collection ProjectData Collection Framework (cosmos-dc-incubation-COSMOS-1.0.0-<build-date>.zip)
Data Visualization ProjectData Reporting Web Application (cosmos-dr-incubation-COSMOS-1.0.0-<build-date>.zip)
Resource Modeling ProjectSML validator and SML-IF Editor (cosmos-rm-incubation-COSMOS-1.0.0-<build-date>.zip)
Management EnablementNA



Build Dependencies

Dependency Name Version
Eclipse SDK (http://www.eclipse.org/downloads/) ver 3.3
Dojo Toolkit (http://dojotoolkit.org/) Rel 0.4.2
BIRT Runtime (http://download.eclipse.org/birt/downloads/) Rel 2.2.0
Orbit Bundles (http://www.eclipse.org/orbit/) Rel R200706192011
Equinox Bundles (http://www.eclipse.org/equinox/) ver 3.3RC4


Build Env

Current build environment is as follows:
OS – Linux - Hat Enterprise Linux AS release 4 (Nahant Update 5)
Java – IBM Java 1.5 (ibm-java2-i386-50)

Build Repositories
1) dev.eclipse.org:/cvsroot/org.eclipse - www/cosmos (eclipse server web interface)
2) dev.eclipse.org:/cvsroot/technology - org.eclipse.cosmos (build artifacts & rel engg)

Build Process

This sections explains the following
1) Build Schedule
2) Build Types
3) Build Control & Management


1) Build Schedule
1a) Daily Builds
An automated build runs every 24 hours. The state of the head branch of the CVS repository will be labeled with a time stamp. The time stamp will be encoded with the release number, date, time, and serial build number, eg: COSMOS-RMm-YYMMDDHHMMSS. A module list will be maintained (in CVS) that lists all the modules that are part of the current build, labeling and extracting will be restricted to those modules.

1b) Manual Builds
Apart from the daily automated builds, a manual build can be started by those who are authorized to do so.
{TBD: How to start the manual build on eclipse server}

2) Build Types
The different types of builds available are:
2a) Development Builds
2b) Candidate Builds
2c) Stable Builds
2d) Release Builds

2a) Development Builds
All successful daily builds are published to the eclipse server as development builds. Development builds are produced from whatever has been released into the HEAD stream of the CVS repository. They are completely untested and may contain major problems. These drops are normally only useful to developers actually working on this project.

2b) Candidate Builds
Selected daily builds are promoted as candidate builds for testing, based on the iteration schedule. They can be promoted to either milestone or release builds.

2c) Stable Builds
Candidate builds which pass all the test phases & bugs fixed are flagged as stable builds. Stable builds are tested drivers delivered at the end of each iteration of the development cycle. The latest stable build is the right build for people who want to stay up to date with what is going on in the latest development stream, and don't mind putting up with a few problems in order to get the latest greatest features and bug fixes. Stable builds are also known as milestone builds

2d) Release Builds
According to the release schedule the stable builds are released to the community. Releases are builds that have been declared as major releases by the development team. Releases are the right builds for people who want to be on a stable, tested release.


Note: Tagged vs Untagged Builds
When a build is tagged, the artifacts used in build are tagged in CVS using the build ID. This is for easily reproducing the build if needed. All nightly builds are tagged builds. Manual builds have the option to run as tagged or untagged.

3) Build Control & Management
As explained above, the daily build starts automatically and the manual build has to be initiated by a person. If a build is in progress, another build cannot be started. A ".busy" file is created when the build starts and is removed automatically once it is over. The build output contains the deliverables, log files and reports.

The Release Engineering Team will be responsible for running the builds and tests to completion. In the event of problems with the build & test system, they are expected to be resolved as soon as possible and get the build and test restarted. In the event of problems with the build caused by developer checkins it is followed up with developers to ensure fixes are made quickly, and then the build and test are restarted. Any build failure will be reported through bugzilla to the build component for tracking the actual issue as well as trend analysis, etc. All committers are responsible for clean builds and tests. Anytime a check-in is made, the respective person is responsible for monitoring the builds and tests until they pass.


Publishing the build
At the end of a successful build, the build output is published to the eclipse server as development build, as part of the build process.

Once the build progress through the different phases, it evolves into stable or release builds. Changing the build can be done by editing the file www/cosmos/downloads/publish_1.0.0.txt in repository dev.eclipse.org:/cvsroot/org.eclipse

format: {development/candidate/stable}|{build id}|{comments}
eg: stable|COSMOS-1.0.0-200708171630|i5 stable build (Release 0.5)

Build Setup

Eclipse PDE Build
Cosmos build is based on Eclipse PDE build. The Plug-in Development Environment (PDE) provides tools to create, develop, test, debug, build and deploy Eclipse plug-ins, fragments, features, update sites and RCP products. PDE is built atop the Platform and JDT, and ships as part of the Eclipse SDK. The goal of PDE Build is to facilitate the automation of plug-in build processes. Essentially, PDE Build produces Ant scripts based on development-time information provided by, for example, the plugin.xml and build.properties files. The generated Ant scripts, can fetch the relevant projects from a CVS repository, build jars, Javadoc, source zips, put everything together in a format ready to ship and send it out to a remote location (e.g., a local network or a downloads server).

For more info on PDE build, refer:
http://www.eclipse.org/pde/pde-build/
http://www.eclipse.org/articles/Article-PDE-Automation/automation.html
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_feature_build.htm

Build Environment
Currently COSMOS build is performed at two Linux based machines. One machine performs source code compilation/packaging and another machine performs front-end functions. The build is started from the front-end machine, which initially fetch the build module from CVS and save it at workspace directory on compilation machine. The fetched build module contains various Bash/Ant scripts to perform the complete build. These Bash/Ant scripts broadly perform following functions:

1) Fetch plugins/features from CVS
2) Compile the fetched code to .class files
3) Assemble the .class files to .jar file
4) Package the jars as .zipped file
5) Publish the zipped files to COSMOS download page.

Adding/changing a dependency
Adding a new dependency or modifying an existing one is done by changing the following files:
a) build.properties - in dev.eclipse.org:/cvsroot/technology/org.eclipse.cosmos/releng/org.eclipse.cosmos.releng.builder/runtime
b) customTargets.xml - in dev.eclipse.org:/cvsroot/technology/org.eclipse.cosmos/releng/org.eclipse.cosmos.releng.builder/runtime

Adding/changing a component



Connecting CVS with SSH
These build machines includes an SSH client for accessing a remote CVS server. Different methods can be used to authenticate, depending on the level of functionality and security Authentication methods used by the client by default are, in the following order: public-key, Keyboard-Interactive, and password authentication.

Public-key authentication allows the client to connect to a remote CVS server without sending the password. This is a more secure authentication method than password authentication. Public-key authentication uses two keys, a private key that it should be kept in a secure place and protected with a password. And the public key, is placed on the server, one wish to gain access to.

Reference: [1] Eclipse SDK help

Build Contacts

The release engineering team is responsible for starting the build. In case of any build failure, please contact the release engg team. Following are the release engg team members:

IBM:
Balan Subramanian (bsubram at us.ibm.com)
Jagmit Singh (jagmits at ca.ibm.com)
Bobby Joseph (bobbyjoseph at in.ibm.com)

Links to Bugzilla

Open bugs against Release Engineering team

Back to the top